Správa o ceste ICSE 2018: 50 rokov softvérového inžinierstva

Väčšina generálnych predsedov a programových predsedov zo všetkých 40 zasadnutí ICSE.

Tento rok je oblasť výskumu softvérového inžinierstva 50 rokov; najväčšia, najstaršia a najlepšia konferencia v oblasti softvérového inžinierstva, Medzinárodná konferencia o softvérovom inžinierstve, je stará 40 rokov. Tohtoročná konferencia bola pre komunitu veľkou príležitosťou obzrieť sa za posledných polstoročím výskumu a opýtať sa: „Čo sme sa naučili? Na čo sme zabudli? Čo nám chýba? “Týždeň som strávil celý týždeň v švédskom Göteborgu, zaoberajúc sa touto otázkou, premýšľajúc o mnohých dôvtipných kľúčových prejavoch a rozhovoroch, ktoré na tieto otázky odpovedali, ale tiež som sa podelil o svoje vlastné myšlienky o tom, ako napredovať dvoma pozvanými rozhovormi.

Na rozbehnutie môjho prvého celého dňa som uviedol úvodnú prednášku v úložisku banského softvéru.

Začal som svoj čas na ICSE, kde som na ICPC 2018 a MSR 2018 predniesol spoločnú hlavnú myšlienku o nevyhnutnosti interdisciplinárnej práce a teórie vo výskume softvérového inžinierstva. Ako príklady pre tieto väčšie body som použil komunity, ktoré sa zameriavajú na porozumenie a ťažbu. O mojom vystúpení som písal v predchádzajúcom príspevku so zhrnutím svojich argumentov. Po mojom prednášaní a počas konferencie som sa zapojil do skutočne zaujímavých rozhovorov s oboma vedúcimi výskumníkmi, ktorí sa snažili porozumieť tomu, čo som myslel teoreticky, ale aj novým Ph.D. študenti fascinovaní potenciálom teórie zefektívniť svoju prácu. Mal som veľkú skupinovú konverzáciu s niekoľkými doktorandmi CMU o tom, čo je to teória, ako to vyzerá, ako to môže zmeniť štúdie, ktoré robíme, a ako to môže zvýšiť naše výsledky. Tiež som hovoril s inžinierom z Adobe Analytics, ktorý sa snažil získať interných osvojiteľov analytických nástrojov. Bola to fascinujúca príležitosť pokúsiť sa ovplyvniť to, ako budúca generácia výskumných pracovníkov a inžinierov začleniť teóriu do práce, ale prinútilo ma zaujímať, ako efektívne učiť teóriu.

V pondelok som nejaký čas trávil na zasadnutiach MSR a ICPC, keď som sa dozvedel o najnovších prieskumoch vo vnímaní chybových správ, porozumení vzorovým vzorom a inému úsiliu preskúmať zrozumiteľnosť. Jeden príspevok replikoval hodnotenie 121 komplexných metrík súvisiacich s kódom, aby zistil, či korelovali so skúsenosťami zrozumiteľnosti, ktoré vývojári sami uviedli, a zistil, že názvy dĺžok a premenných spoločne predpovedali ratingy vývojárov. Na týchto menších konferenciách, ktoré sa nachádzajú blízko seba, existuje niekoľko skutočne dômyselných údajov, ktoré kladú skutočne presvedčivé otázky na križovatke porozumenia a ťažby. Ako som uviedol vo svojej hlavnej poznámke, skutočne potrebujú teóriu porozumenia, ale vzorce, ktoré nachádzajú, sú dobrým základom pre rozvoj týchto teórií.

V pondelok popoludní som mal strhujúci rozhovor s Timom Menziesom o relatívnych prednostiach hlbokých a plytkých modelov. S prekvapením odpovedal na moju hlavnú myšlienku, že som neurobil hlbšie kritiky komunity ťažby úložísk, ale tiež, že som neuznal niektoré ohromujúce sily jednoduchých plytkých modelov na optimalizáciu a škálovanie všetkých druhov rozhodnutí v softvéri. inžinierstva. Jeho argumentom bolo v podstate to, že v niektorých prípadoch alebo možno v mnohých nemusíme vysvetľovať, prečo fungujú nástroje, systémy alebo procesy. Rozhádali sme nezhody a nakoniec sme dospeli k záveru, že pravdepodobne potrebujeme modely všetkých druhov hĺbok (od teórií po nevysvetlené zákony až po bezdôvodné, ale presné prediktívne motory). Takáto rozmanitosť je pravdepodobne príznakom zdravého akademického diskurzu.

Banket MSR v Gothenburgskom múzeu svetovej kultúry.

V pondelok v noci bola banketom konferencia úložísk softvéru pre ťažbu. Mal som veľa rozhovorov s Mei Nagappanom, Andym Zaidmanom a Michaelom Godfreyom. Hovorili sme o všetkom, od držby a povýšenia, výučbe CS v mierke, našej osobnej histórii okolo výučby po program a našich úlohách gatekeepers vo výučbe CS. Pre mňa sú takéto rozhovory hlbokou podstatou akademických sietí: sú to rozhovory o našich životoch, našich nápadoch a spôsobe ich interakcie.

Abram hovorí o potrebe postupného vedeckého pokroku.

V utorok ráno predniesol Abram Hindle najvýznamnejšiu novinársku cenu o svojom príspevku: „Čo nám hovoria veľké záväzky? Taxonomická štúdia o veľkých zákazkách? “Čo bolo na tomto článku významné, je to, že to bol jeden z prvých dokumentov, ktorý nielenže pokročil v ťažbe, ale v skutočnosti sa pýtal na obsah úložísk a posunul pole smerom k vedeckejším otázkam o softvéri. strojárstvo, nielen techniky ťažby. To, čo sa mi na práci skutočne páčilo, bolo, ako to považovalo za vedecky podložené: silno tvrdilo, že extrémne hodnoty sú dôležité a nie ignorovateľné a že veľké odľahlé externé reťazce boli skutočne kritickými ukazovateľmi o povahe vývoja softvéru. Taktiež sa jedinečne zameriavala na podrobnú obsahovú analýzu záväzkov, ktorá bola (a stále je) zriedkavou metódou v akomkoľvek výskume v oblasti prieskumu dolovania údajov. Abram tiež presvedčivo tvrdil, že odmietnutie dokumentov za to, že výsledky nemajú okamžite uskutočniteľné, ovplyvňuje našu vedu, a teda našu budúcnosť, a je v rozpore s tým, o čom je štipendium. V otázke a odpovedi Abram uviedol niekoľko zaujímavých informácií o ekonómii výskumu a o tom, ako môže zvrátiť otázky, ktoré sledujeme, a hĺbku vedeckého skúmania, ktoré povoľujeme.

Počas prestávky sa ma Lutz Prechelt pýtal fascinujúcou otázkou: Prečo je to tak, že napriek tomu, že softvér je tak zložitý a vývojári sú tak nepripravení, tento softvér sa napriek tomu stáva budovaným, adoptovaným a produktívnym spôsobom používaným? Na chvíľu som sa zamyslel a zdieľal som svoju veľkú teóriu. Moje vysvetlenie bolo, že softvér má, napriek tomu, že má skutočne nekonečný stav poprav, a je vývojárom nekonečne nepochopiteľný, v skutočnosti má iba malý relevantný priestor štátov, ktorý používatelia používajú v praxi. To znamená, že napriek tejto komplexnosti sú vývojári schopní získať len dostatok vedomostí o tomto relevantnom priestore spustení a zabezpečiť, aby bol softvér pre nich efektívny a robustný. Potom, aj keď softvér nie je efektívny a robustný, mám podozrenie, že používatelia sú odolní voči väčšine zlyhaní, s ktorými sa stretávajú, pri hľadaní riešení alebo pri zmene svojich cieľov na základe správania. Táto teória odolnosti vysvetľuje, prečo je softvér cenný napriek tomu, že je krehký. To však neznamená, že zlyhania softvéru nie sú dôležité: existujú závažné zlyhania a často vznikajú z toho, že vývojári nemajú presnú predstavu o tom, na ktorých častiach stavového priestoru komplexného softvérového systému v skutočnosti záleží. Vývojári navyše často nemajú nástroje ani údaje potrebné na získanie týchto presných znalostí. Okrem toho existuje veľa podzložiek systémov, ktoré sú čisto automatizované, a preto musíme byť schopní formálne overiť, aby sa predišlo vážnym zlyhaniam po prúde. Existujú tiež významné úvahy o počte ľudí v slučke, ktoré si vyžadujú osobitnú pozornosť, aby sa dostali do poriadku, čo si vyžaduje metódy HCI. Takže rovnako odolný ako svet je krehký softvér, môžeme a musíme robiť lepšie.

V utorok som si urobil prestávku, aby som vedel strhujúci rozhovor s juniorským kolegom o tom, ako radiť študentom doktorandov. Položil vynikajúce otázky, ktoré mi poskytli vynikajúci základ na zamyslenie sa nad mojimi postupmi. Veľa som hovoril o definovaní kultúry a mojej novej stratégii písania palubného dokumentu, ktorý stanovuje očakávania. Hovoril som o psychologickej bezpečnosti ako o základoch budovania dôveryhodných vzťahov so svojimi študentmi a so svojím tímom. Hovoril som o kritickej potrebe skutočného presadzovania a modelovania noriem v mojom palubnom dokumente na posilnenie kultúry môjho laboratória. Podelil som sa o myšlienky týkajúce sa spolupráce študentov s cieľom zvýšiť zodpovednosť, rozmanitosť nápadov a frekvenciu spätnej väzby. Diskutoval som tiež o napätiach pred držbou, ktoré môžu vyplynúť z potreby publikácií, ale tiež o potrebe dať priestor pre študentov, aby sa učili, ao tom, ako tieto napätia vyriešiť udržiavaním samostatnej časti prvého autorského výskumu. Čo je najdôležitejšie, pripomenul som tomuto kolegovi, že toto učenie sa nekončí. Poznám starších kolegov, ktorí sa po desaťročiach vzdelávania stále radia.

V utorok večer som mal úžasnú večeru s Thomasom LaTozom a Ph.D. študent August Shi, v ktorom sme viedli rozsiahlu diskusiu o základnom a aplikovanom výskume softvérového inžinierstva, o úlohe spoločenských vied vo výskume softvérového inžinierstva a o potrebe čestnejších, teoreticky podložených správ o základných predpokladoch technickej práce v tejto oblasti.

Magnus Frodigh, predseda predstavenstva spoločnosti Ericsson Research, predniesol v stredu úvodnú prednášku o bezdrôtových komunikáciách a 5G. Začal predpovedaním rýchleho tempa zmien v našich digitálnych skúsenostiach, ale aj pomalšieho tempa zmien v sieťovej infraštruktúre. Tvrdil, že stabilita štandardu 5G by sa týkala všetkých druhov novej transformačnej infraštruktúry v IoT vrátane komunikácie medzi strojmi v reálnom čase. Hlboko sa ponoril do podrobností o 5G infraštruktúre, ktorú som považoval za suchú a väčšinou irelevantnú pre softvérové ​​inžinierstvo, ale presvedčivou víziou ukrytou vo vnútri rozhovoru bola nepredstaviteľná škála prepojiteľnosti medzi ľuďmi a strojmi, ktorá prichádza so zásadným vylúčením latencie. Magnus tvrdil, že to výrazne zjednoduší vytváranie nových skúseností s prototypmi, pretože systémy môžu byť zložené výlučne prostredníctvom sieťových služieb s nízkou latenciou, a nie prostredníctvom nasadenia hardvéru.

Počas stredajšej rannej prestávky sme s Walterom Tichym a Jamesom Herbslebom viedli produktívny rozhovor o tom, ako transformovať využitie a vývoj teórie v softvérovom inžinierstve. Začali sme pozorovaním toho, ako pole má teórie, sú iba implicitné, a ak budú vyjadrené explicitne, môžu spôsobiť, že prehodnotíme naše predpoklady a naše výskumné smery. Napríklad pole obsahuje teórie sily abstrakcie, predstavy o chybovosti v návrhu programovacieho jazyka a spôsob, akým funguje porozumenie programu. Tieto teórie jednoducho nevysvetľujeme. James predniesol aj hlavnú myšlienku teórie a on a ja sme obaja obdržali vrelé odpovede na naše výzvy na viac teórie, takže máme podozrenie, že je pole pripravené sa učiť. Zamysleli sme sa nad spôsobmi vzdelávania komunity, vrátane vývoja niektorých ľahkých materiálov na výučbu nových doktorandov alebo záujemcov. Diskutovali sme o možnom usporiadaní Dagstuhl na vývoj a nasadenie týchto materiálov.

Chris Parnin diskutuje o komplexne zložitosti výučby.

Zvyšok stredu som strávil účasťou na školeniach o vzdelávaní a školení v oblasti softvérového inžinierstva (ktorým budem spolupredsedať v roku 2020, ale tiež si myslím, že je dosť dôležitý a stredobodom môjho záujmu o počítačové vzdelávanie). Táto skladba publikuje prísny, recenzovaný výskum počítačového vzdelávania o softvérovom inžinierstve. Chris Parnin odštartoval prvé sedenie prednáškou o použití rozsiahlej komplexnej implementácie softvéru iTrust na výučbu softvérového inžinierstva. Zistil, že študenti ocenili oveľa neskôr po ukončení kurzu hlbokú angažovanosť s rozsiahlym komplexným systémom, ale počas kurzu sa im to vôbec nepáčilo. Práca so starým kódom bola ohromujúca. Kurz upravili zosúladením aktivít triedy so samotným projektom, čo viedlo k oveľa pozitívnejším pocitom o kurze (ako sa očakávalo; študenti potrebujú súvislý príbeh okolo aktivít triedy, aby si udržali svoju angažovanosť). Ďalšia prednáška zistila, že aktívne sledovanie videa, v ktorom študenti komentujú obsah a komentujú recenzie, zvyšuje zapojenie do sledovania videa. Niektoré prednášky boli zamerané na laboratóriá, kamienky a iné projekty zážitkového vzdelávania. Všeobecne tieto štúdie zistili, že zážitkové učenie je skutočne ťažké vykonať logisticky, je náročné urobiť autentické a veľmi ťažké vedieť, ako ich vyhodnotiť. Znie to, akoby sme potrebovali nejaké teórie zážitkového vzdelávania, aby sme mohli túto prácu zorganizovať.

Reid Holmes diskutuje o veciach, ktoré sa študenti učili.

Reid Holmes predstavil pekné dlhodobé štúdium kanadského zážitkového vzdelávacieho programu pre vysoko výkonných študentov počítačovej vedy (bakalárske projekty Capstone Open Source). Štúdia odhalila ohromujúce pozitívne skúsenosti so študentmi, ktorí vysoko oceňujú aplikáciu svojich vedomostí v triede na skutočné nové úlohy, na skutočné projekty s komunitou používateľov a zároveň získavajú mentorstvo od skutočných vývojárov. Temným nedostatkom tejto práce je spôsob, akým sú študenti vyberaní: program si výslovne vyberá najlepších študentov z viacerých inštitúcií, čím sa vyhýba mnohým vzdelávacím výzvam, ktoré by sa mohli vyskytnúť s menej pripravenými študentmi.

Dažďový prales Universeum bol skutočne vlhký!

V stredu v noci bola recepcia v Universeum, prírodovednom múzeu plnom zvierat, rýb a masívneho vlhkého dažďového pralesa. Bol to skutočne zaujímavý kontext pre recepciu, pretože skôr ako veľký otvorený priestor na konverzáciu bol plný interaktívnych výstav, ktoré zapojili účastníkov do hry a prieskumu. Exponáty neboli zvlášť príjemné ani presvedčivé, boli však dosť dobré na to, aby vyvolali všetky zaujímavé rozhovory, ktoré by sme pravdepodobne inak nemali. Hovoril som s účastníkmi o monštrách Gíly, štrkáčoch, medúzach, údržbe softvéru softvérových exponátov a širokom spektre cynizmu, ktorý sa dostal do akademickej informatiky.

Vo štvrtok ráno som mal raňajky s Brendanom Murphym, Laurie Williamsovou a UW Ph.D. študent Calvin Loncaric v našej hotelovej raňajkovej miestnosti. Mali sme rozsiahlu diskusiu o dvoch veľkých výzvach, ktoré mi v srdci boli: zladenie formálnych systémov, ako sú programovacie jazyky, s ľudskými a sociálnymi systémami, a zladenie štatistických systémov, ako je strojové učenie, s ľudskými a sociálnymi systémami. Podľa môjho názoru sú to dve najdôležitejšie veľké výzvy v oblasti informatiky, ale väčšina ľudí v oblasti informatiky ich ignoruje. Brendan mal veľa čo povedať o zložitosti zjednotenia analýzy údajov a strojového učenia so skutočnými projektmi, Laurie veľa hovorila o rovnakých výzvach pri účtovaní bezpečnosti pri vývoji softvéru a Calvin tieto problémy zvažoval vo svojej vlastnej práci na syntéze štruktúry údajov, kde otázky týkajúce sa zrozumiteľnosti syntetizovaného kódu a znalosti jeho jazyka špecifikácie sú otvorenými otázkami.

Fred Brooks Jr., interpretácia histórie.

Vo štvrtok ráno boli dve hlavné prednášky. Retrospektíva dáva Fred Brooks, Jr., autor seminára The Mythical Man-Month o softvérovom projekte. Fred hovoril o vývoji programov, softvéru, softvérových systémov, softvérových produktov. Softvérové ​​inžinierstvo potom definoval ako disciplínu pri výrobe softvérových produktov. Hovoril o veľkých nápadoch v histórii softvérového inžinierstva, vrátane programov von Neumanna ako dátových a programovacích jazykov na vysokej úrovni ako COBOL a FORTRAN. V 60. rokoch viedla softvérová kríza (výzva na vybudovanie veľkých systémov) k myšlienke softvérového inžinierstva ako inžinierstva. Veľkým uznaním bolo, že rast zložitosti projektu nebol lineárny. To veľa viedlo k systémovým príspevkom, ako je interaktívne ladenie Toma Kilburna a operačný systém zdieľania času Fernanda Corbata, databázové systémy, nápady Roberta Floyda a Tonyho Hoareho na formálne overenie a objektová orientácia Simuly. V 70. rokoch sa objavili informačné skrinky Davida Parnasa, abstraktné typy údajov Barbary Liskovovej, prírastkové vylepšenia Harlan Mills a Niklaus Wirth, inšpekcie kódu Michaela Fagana a riadenie softvérových projektov. Barry Boehm tiež položil otázky týkajúce sa validácie požiadaviek a požiadaviek. Dôrazne odporučil webový seminár ACM spoločnosti Grady Booch o histórii softvérového inžinierstva a celoživotných príspevkoch Barryho Boehma.

Margaret Hamiltonová delí príbehy o programovaní mainframe.

Druhým štvrtkovým prednášajúcim vo štvrtok ráno bola Margaret Hamiltonová, ktorá si predstavila frázu „softvérové ​​inžinierstvo“. Študentka matematiky, keď sa rozhodla pre stáž na MIT vyvíjajúcu softvér pre počasie na LGP30, rozvíjala záujem o softvér a nakoniec postavila Apollo softvérové ​​systémy, ktoré umožnili USA pristáť na Mesiaci. V prednáške „The Language as a Software Engineer“ sa hovorilo o veľkých problémoch: integrácia, vývojová náročnosť, opakované použitie je ťažké a softvér zlyháva. Spýtala sa, prečo sme za 50 rokov dosiahli taký malý pokrok? Tvrdila, že nejaké bolo. Predtým nebolo pole; teraz existuje. Definovali sme výrazy. Realita je však taká, že softvérové ​​inžinierstvo je výrazne ľudská, zreteľne sociálna a výrazne intelektuálna práca a stále sa s väčšinou týchto faktorov nezaoberáme. Uviedla príklady základných výziev HCI, ktoré sa týkajú vytvárania interaktívnych systémov medzi ľuďmi, softvérom, chybami a obnovou chýb a ako boli tieto ťažkosti pri pristávaní na Mesiaci. Uvedomila si, že systémy sú asynchrónne, distribuované a riadené udalosťami a že jazyky používané na písanie softvéru by to mali odrážať. Vyvážila to diskusiou o potrebe plánovania prostredníctvom architektúry pomocou opakovane použiteľných a spoľahlivých vzorcov. Bol som hrdý na to, že v odpovediach na otázky a odpovede som videl, ako komunita uznáva históriu, jej hodnotu a vzdialený pôvod niektorých najväčších nápadov v tejto oblasti.

Miryung Kim z UCLA hovorí o fascinujúcej štúdii úloh vedy o údajoch.

Vo štvrtok som predsedal schôdzi s názvom „Štúdium softvérových inžinierov“, ktorá mala štyri fascinujúce empirické štúdie, vrátane dvoch publikácií TSE, ktoré boli prvýkrát publikované v časopise. Prvý dokument „Pochopenie potrieb vývojárov pri odpisovaní ako jazykovej vlastnosti“ (autor: Anand Sawant z TU Delft) odhalil mnoho užitočných trendov týkajúcich sa používania a zneužívania odpisových funkcií, zisťovania potrieb dátumov odpisovania, závažných varovaní a väčšej rozmanitosti. typov varovaní. V druhom článku „O dichotómii ladiaceho správania medzi programátormi“ (autor Moritz Beller z TU Delft) sa zistilo, že v praxi sa nástroje na ladenie používajú zriedka, že „ladenie na tlač“ je dominantné a znalosť nástrojov na ladenie je pomerne veľká. nízka. Prvý novinový článok v sekcii „Meranie porozumenia programu: rozsiahle terénne štúdium s profesionálmi“ (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing a Shanping Li) zistil, že vývojári trávia väčšinu času porozumením. kód, ktorý používajú webové prehliadače a editory na porozumenie kódu a že čím viac skúseností má vývojár, tým menej času trávi na porozumení. Posledný príspevok v sekcii „Vedci údajov v softvérových tímoch: najmodernejšie a výzvy“ (Miryung Kim, Thomas Zimmermann, Robert DeLine a Andrew Begel) uskutočnil prieskum 793 vedeckých pracovníkov s údajmi a zistil, že je skutočne zaujímavý súbor 9 typov úloh vedy o údajoch: polymathi, evanjelisti údajov, pripravovatelia údajov, tvorcovia údajov, tvorcovia platforiem, mesačníci rôznych stupňov a insightoví aktéri, ktorí údaje interpretovali a používali na rozhodovanie. Táto bohatá dekonštrukcia alebo rôzne úlohy sa javia ako skutočne výkonné pri informovaní o výučbe prírodných vied.

Posledné zasadnutie vo štvrtok bolo oslavou 50 rokov softvérového inžinierstva. Brian Randell poskytol retrospektívu v súvislosti s prvým softvérovým inžinierstvom už v roku 1968. Brian hovoril o tom, ako málo bolo doteraz vynájdené o počítačoch; žiadny internet, žiadne siete, žiadne opätovné použitie. A napriek tomu tu boli všetky problémy: testovanie, správnosť, riadenie atď. Brian rozlišoval medzi programovaním a softvérovým inžinierstvom definovaním softvérového inžinierstva ako „Vývoj viacerých osôb pre programy pre viac osôb“. , ale David Parnas trvá na tom, že áno). Dospel k záveru, že toto pole sa rozrástlo viac, ako dozrelo, a pýtal sa, či sme sa dostali dosť ďaleko na to, aby sme ho nazvali inžinierskou disciplínou, a pokúšajúc komunitu vymýšľať ďalší jazyk a inú techniku.

Po Brianovom vystúpení nasledoval panel štyroch pôvodných účastníkov konferencie v roku 1968. Jednou z otázok, ktorú prediskutovali, bolo to, čo za posledných päťdesiat rokov ľutovali. Zdôraznili nedostatok zamerania na technické požiadavky, nedostatok pozornosti na dezinformácie, nedostatok pozornosti na údržbu softvéru. V 60. rokoch boli sklamaní a teraz sú sklamaní. Niektorí panelisti boli nadšení formálnymi metódami, ale sklamaní nedostatkom adopcie. Boli tiež sklamaní z toho, ako málo sme sa dozvedeli o tom, ako riadiť rozhodnutia týkajúce sa dizajnu vo vzťahu ku kvalitám softvéru. Celkovo sa však zdalo, že existuje len malý konsenzus o tom, či sa veci zlepšili alebo nie. Budujeme určite zložitejšie veci, ale sú o niečo lepšie, viac načas?

Ryby, krycie pásky a prezentácie

Vo štvrtok večerná banket bola v lodenici a bola divnou pasticou aktivít. Bolo tu banketové jedlo, vonkajšie pódium s Ph.D. študenti spievajúci rockovú hudbu a švédska krycia skupina, ktorá počas večere spievala popové piesne 90 a 2000, zatiaľ čo hosteska oslávila komunitu softvérového inžinierstva a na javisko pozvala rôznych organizátorov konferencií, aby sa poďakovali. Počas večere sa prezentácia hrávala so všetkými druhmi ľubovoľných log softvérových produktov z histórie výpočtovej techniky, s občasným retrospektívnym videom s rozhovormi s predstaviteľmi softvérového inžinierstva. Bolo to šialené, nesúvislé a dezorientujúce, najmä keď partia účastníkov vybojovala tanečný kútik priestoru podujatia.

Softvérové ​​tanečné párty!Robert McClure, jeden z účastníkov konferencie NATO v roku 1968.

V piatok ráno som našiel jedného z panelistov z štvrtkového restrospektíva Roberta McClurea, ktorý sedel počas prestávky sám, a tak som sa rozhodol začať rozhovor. Bol jedným z pôvodných účastníkov konferencie v roku 1968 a bol aktívnym vodcom myslenia v priemysle, ktorý obhajoval pokrok. Spýtal som sa ho na to, čo sa za 50 rokov zmenilo, čo sa nestalo a aké je jeho poňatie pokroku. Mali sme fascinujúci, rozsiahly rozhovor o mnohých základných problémoch v softvérovom inžinierstve. Začal diskusiou o niektorých kritických rozdieloch medzi návrhom toho, čo softvér robí (čo si vyžaduje pochopenie problému a jeho kontext), inžinierskym dizajnom (ktorý vyžaduje starostlivo špecifikovanie riešenia) a inžinierstvom (čo je čisto implementáciou tejto špecifikácie). Robert porovnával softvérové ​​inžinierstvo s inými inžinierskymi disciplínami, a tak som sa ho opýtal, čo považuje za základné rozdiely, ak nejaké existujú. Navrhoval, že to bola otázka stupňa. Špekuloval som, že kritickým rozdielom je miera, do akej môže byť dizajnér alebo strojársky dizajnér presvedčený, že pochopia problém alebo špecifikáciu; porozumenie stránky, na ktorej staviate most, závisí od prírodných vied, ktoré sú predvídateľné do tej miery, že to neplatí pre ľudské, sociálne a organizačné systémy, pre ktoré je softvér obvykle navrhnutý. Táto nedôvera vytvára potrebu prototypovania, spätnej väzby a vývoja, ktoré nie sú také potrebné pre iné inžinierske disciplíny (a tiež nie také realizovateľné). Hovorili sme tiež o vzdelaní potrebnom pre všetky tieto zručnosti ao miere zmeny, ktorú očakával. Očakával v posledných 50 rokoch omnoho viac zmien, ako si všimol, a špekuloval, že ľudská povaha je oveľa odolnejšia voči zmenám, ako kedy veril. Navrhoval som, že by to mohlo byť len zlyhanie efektívneho vzdelávania v kombinácii s rýchlym nárastom počtu vývojárov z približne 10 000 v roku 1968 na 30 miliónov v roku 2018. Povzbudil ma, aby som zmiernil moje očakávania týkajúce sa zmeny; Povedal som mu, že ako profesor v odbore, bol som v ňom ďalších 40 rokov a bol by som trpezlivý.

Brian Randell, historik softvérového inžinierstva.

Náhodou som tiež našiel Briana Randella, štvrtkového 50-ročného rečníka softwarového inžinierstva, ktorý sedel sám. Spýtal som sa ho, prečo je presvedčený, že 2. konferencia NATO bola tak sklamaná, a aký vplyv mal podľa neho na nadchádzajúce desaťročia výskumu a praxe softvérového inžinierstva. Tvrdil, že veľká časť problému spočíva v tom, že v 2. roku existovali rozdiely pozdĺž dvoch. Po prvé, niektorí ľudia predpokladali svet, v ktorom by sme mohli dodávať úplne bezchybný softvér, a iní verili, že takáto vec nie je možná, a mali by sme ju naplánovať. V druhej dimenzii sa niektorí ľudia zaujímali o dekonštrukciu problému softvérového inžinierstva a iní sa zaujímali o nástroje, techniky a ďalšie riešenia, ktoré by podľa neho mohli vylepšiť. Účastníci rozdelení podľa týchto riadkov jednoducho nemohli vyjsť. Idealisti a realisti nevedeli, ako spolupracovať a problém zameraný na problém trávil príliš veľa času kritizovaním riešení ľudí zameraných na riešenie, zatiaľ čo ľudia zameraní na riešenie boli odolní voči spätnej väzbe. Navrhol som, že mnohé z týchto divízií stále existujú v modernom výskume softvérového inžinierstva a poďakoval som Brianovi za pomoc pri osvetlení historického pôvodu týchto divízií.

Ivar otvára svoju hlavnú príbeh príbehom.

Ivar Jacobson, hlavný prispievateľ do UML a Rational Unified Process, predniesol prednášku s názvom „50 rokov softvérového inžinierstva, tak čo teraz?“ Začal anekdotou o jednom zo svojich prvých projektov softvérového inžinierstva, kde musel priznať. , nevedel nič o softvérovom inžinierstve. A napriek tomu stále viedol jeden z najúspešnejších švédskych výrobkov v histórii. Jeho interpretácia úspechu softvéru je v konečnom dôsledku spôsobená obchodnými modelmi a vývojármi, nie softvérom a nie procesmi. Podľa jeho názoru je to po 50 rokoch ešte viac remeslo ako inžinierska disciplína. V skutočnosti v histórii tvrdí, že sme oveľa viac motivovaní módou ako vedou: objektová orientácia, UML, CMMI, Agile a všetko, čo bude ďalej, boli a budú módou. Ivar argumentoval tým, že všetky metódy vojen boli rozptýlením. Skutočným problémom je podľa Ivara skutočnosť, že metódy sú skutočne zložením praktík a metódy sú monolitické a uväznené vo väzeniach strážených gurumi. Podľa názoru Ivara je to nezrelé a hlúpe.

Jeho odporúčanie bolo zamerať sa na nájdenie spoločného základu o metódach, modularizáciu metód a bezplatné praktiky z metód. Hovoril o normotvornom orgáne, ktorý predpokladal pojem postupov, ktoré majú činnosti, ktoré majú určité kritériá úspechu, a pracovné produkty, ktoré pochádzajú z činností, ktoré sa hodnotia na základe týchto kritérií úspechu. Jeho kľúčovým bodom je však to, že všetky tieto skutočnosti vyžadujú, aby vývojári mali kompetencie vo všetkých týchto veciach. Kritériá úspechu sa znižujú podľa potrieb zákazníka, vyrábaného riešenia a tímu na jeho dosiahnutie. Uviedol niekoľko ďalších podrobností o stavoch, ktorými prechádza vo svojom modeli. To, čo mi opísal, znie ako vedecká teória procesu a súbor procesných nápadov odvodených z tejto teórie; niečo, čo sa má otestovať a zdokonaliť, nie evanjelium. Nakoniec to nazval deskriptívnou teóriou a vyzval vedcov, aby ju ďalej rozvíjali v prediktívnu a vysvetľujúcu teóriu.

Ihneď po rozhovore s Ivarom som predniesol svoju prednášku na ICSE Most Influential Paper Award. Uprostred ocenenia som mohol povedať, že ľudia sú unavení a pripravení na koniec týždňa. Moja prednáška mala pochmúrny, reflexný tón, ale povzbudzujúci tón, a hoci ticho po rozhovore bolo ohlušujúce, chatovanie na Twitteri bolo povzbudzujúce, ukázalo komunitu, ktorá skutočne verí a cení si, čo som mala povedať, a má hlad po usmernení ako to spraviť.

Andreas začína svoju prednášku o ocenení

Andreas Zeller prehovorila hneď po mne po získaní výskumnej ceny SIGSOFT Research Award. Uviedol tri príbehy o svojej kariére, všetky zamerané na dopad. Prvý príbeh sa týkal jeho prvého projektu a prezentácie, v ktorej prispel k riešeniu problému. Sklamaný spätnou väzbou sa odrazil sústredením sa na debugger GNU DDD, ktorý mal skutočný praktický dopad. Jeho prvým zjavením bolo, že nájdenie skutočných problémov bolo také dôležité, ale aj skvelý spôsob, ako ovplyvniť. Jeho druhý príbeh bol o jednoduchosti. Niekto na konferencii bol znechutený, že jeho myšlienka delta ladenia bola taká jednoduchá. To viedlo k syndrómu podvodníka, pocitu intelektuálnej podradenosti. Postupom času si však uvedomil, že jednoduchosť je sila; zložitosť bola zlyhanie. Jeho posledný príbeh bol o práci, ktorú začal s Tomom Zimmermannom na úložiskách ťažobného softvéru. Poznamenal, že obavy z výsledkov ich skorej práce jednoducho nezáležali, pretože to bola skutočnosť, že práca bola nová. Inovácia je o štúdiu temne podmanivých, ale dôležitých častí sveta. Andreas nakoniec tvrdil, že jediná vec, na ktorej skutočne záleží, je dopad. Skončil s inšpiratívnou výzvou pokračovať v našich snoch a vytrvať.

Rozlúčiť sa s Gothenburgom je náročné zhrnúť všetko, čo som sa naučil na tohtoročnej ICSE. Ale skúsme aj tak:

  • Nakoniec sme všetci v tejto komunite, aby sme vylepšili softvér. Zamerajme sa na to, nie na krátkodobé metriky.
  • Potrebujeme väčšie nápady, najpravdepodobnejšie vo forme teórií, ktoré nás povedú a povedú náš vplyv.
  • Aby sme dosiahli vyššie uvedené ciele, musíme myslieť na relevantnosť, nie na zverejnenie.
  • V našom softvérovom inžinierstve ignorujeme ľudské faktory.

Toto sú ponaučenia, ktoré musí každý člen našej komunity nakoniec internalizovať. Je to už 50 rokov, čo sme si uvedomili ich dôležitosť, a my ich len začíname brať vážne.