Poročilo o potovanju ICSE 2018: 50 let programskega inženiringa

Večina splošnih stolov in programskih stolov na vseh 40 sestankih ICSE.

Področje raziskav programskega inženiringa je letos staro 50 let; največja, najstarejša in najboljša konferenca programskega inženiringa, Mednarodna konferenca o programskem inženiringu, je stara 40 let. Letošnja konferenca je bila lepa priložnost za skupnost, da se ozre na preteklo pol stoletja raziskav in vpraša: "Kaj smo se naučili? Kaj smo pozabili? Kaj nam manjka? "Teden dni sem v Göteborgu na Švedskem spoznal to vprašanje in razmislil o številnih pronicljivih uvodnih besedah ​​in pogovorih, ki so odgovorili na ta vprašanja, hkrati pa sem delil svoje misli o tem, kako naprej skozi dva povabljena pogovora.

Začetek mojega prvega celotnega dne sem v uvodni izjavi pri Rudarju programske opreme podal uvodno besedo.

Začel sem svoj čas na ICSE, pri čemer sem na ICPC 2018 in MSR 2018 objavil skupno osrednjo besedo o nujnih interdisciplinarnih delih in teoriji v raziskavah programskega inženiringa, pri čemer sem kot primere za te večje točke uporabil skupnosti, ki se osredotočajo na razumevanje in rudarjenje. O svojem govoru sem pisal v prejšnjem postu in povzel svoje argumente. Po svojem pogovoru in po celotni konferenci sem opravil res zanimive pogovore tako z višjimi raziskovalci, ki so se borili, da bi razumeli, kaj mislim pod teorijo, pa tudi z novim doktoratom. študentje so očarani nad potencialom teorije, da bi njihovo delo naredili večji vpliv. Imel sem odličen skupinski pogovor z več doktorskimi študenti CMU o tem, kaj je teorija, kako izgleda, kako lahko preobrazi študije, ki jih izvajamo, in kako lahko naše rezultate poglobi. Pogovarjal sem se tudi z inženirjem iz Adobe Analytics, ki se je trudil, da bi pridobil notranje sprejemalce orodij za analitiko. Bila je fascinantna priložnost, da poskušam vplivati ​​na to, kako bodo naslednje generacije raziskovalcev in inženirjev vključile teorijo v delo, a spraševalo me je, kako učiti teorijo o učinkoviti rabi.

V ponedeljek sem nekaj časa preživel na sejah MSR in ICPC, slišal o najnovejših raziskavah zaznave sporočil o napakah, razumevanju vzorcev vzorcev in drugih prizadevanjih za raziskovanje razumljivosti. V enem prispevku je bila ponovljena ocena 121 zapletenih meritev s kodo, da bi ugotovili, ali so v povezavi z izkušnjo razumljivosti, ki jo je sam poročal razvijalci, in ugotovili, da dolžina in imena spremenljivk skupaj napovedujejo ocene razvijalcev. Na teh manjših soodločenih konferencah je nekaj resnično pametne uporabe podatkov, ki na presečišču razumevanja in rudarjenja postavljajo resnično prepričljiva vprašanja. Kot sem poudaril v svojem zapisu, resnično potrebujejo teorijo o razumevanju, vendar vzorci, ki jih najdejo, so dobra osnova za razvoj teh teorij.

Popoldne v ponedeljek sem imel s Timom Menziesom zaslepljiv pogovor o relativnih zaslugah modelov globokega in plitkega. Deloma je presenečeno odgovoril na mojo opombo, da nisem dal globljih kritik skupnosti za rudarjenje skladišč, ampak tudi, da nisem priznal osupljive moči preprostih, plitvih modelov za optimizacijo in obseg vseh vrst odločitev v programski opremi inženiring. Njegov argument je bil v bistvu ta, da nam v nekaterih primerih ali morda v mnogih ni treba razlagati, zakaj orodja, sistemi ali procesi delujejo, le delati morajo. Nesoglasja smo razblinili in na koncu sklepali, da verjetno potrebujemo modele vseh vrst globine (od teorij do nepojasnjenih zakonov do brezumnih, a natančnih napovednih motorjev). Takšna raznolikost je verjetno znak zdravega akademskega diskurza.

Banket MSR v muzeju svetovne kulture v Göteborgu.

Ponedeljek zvečer je bil pogostitev za konferenco rudniške programske opreme. Imel sem bogat nabor pogovorov z Mei Nagappan, Andyjem Zaidmanom in Michaelom Godfreyjem. Pogovarjali smo se o vsem, od lastništva in napredovanja, učenja na lestvici CS, o svoji osebni zgodovini od učenja do programa in o svojih vlogah vratarjev pri poučevanju CS. Zame so takšni pogovori globoka vsebina akademskega povezovanja: so pogovori o našem življenju, naših idejah in načinu njihovega medsebojnega delovanja.

Abram govori o potrebi po naraščajočem znanstvenem napredku.

V torek zjutraj je Abram Hindle z najpomembnejšo novinarsko nagrado spregovoril o svojem prispevku: "Kaj nam sporočajo velike zaveze? Taksonomska študija velikih naročil? "Kar je bilo pri tem prispevku pomembno, je to, da je bil eden prvih prispevkov, ki ni samo napredoval rudarskih tehnik, ampak dejansko postavil vprašanje o vsebini repozitorij, kar je področje usmerilo k bolj znanstvenim vprašanjem o programski opremi inženiring, ne samo tehnike rudarjenja. Kar se mi je pri delu res zdelo zanimivo, je bilo, kako znanstveno je bil prepričan: odločno je trdil, da so zapuščaji pomembni in ne zanemarljivi ter da so veliki zapuščaji resnično kritični kazalci narave programske opreme. Edinstveno se je osredotočil tudi na podrobno analizo vsebine dokumentov, kar je bila (in še vedno ostaja) redka metoda pri kakršnih koli raziskavah rudarjenja podatkov. Abram je izrazil tudi prepričljiv argument, da zavračanje prispevkov, da rezultati niso takoj dosegljivi, kljubuje naši znanosti in s tem naši prihodnosti in je v nasprotju s tem, kar se štipendije tiče. Abram je v vprašanjih in vprašanjih podal nekaj vpoglednih mnenj o ekonomiki raziskovanja in kako lahko zastavlja, katera vprašanja si prizadevamo in globino znanstvenega raziskovanja dopuščamo.

Med odmorom mi je Lutz Prechelt postavil fascinantno vprašanje: zakaj je kljub temu, da je programska oprema tako zapletena in da so razvijalci tako nepripravljeni, programsko opremo kljub temu zgradili, sprejeli in uporabljali produktivno? Za trenutek sem premišljeval in delil svojo veliko teorijo. Moja razlaga je bila, da programska oprema, čeprav ima dejansko neskončen prostor stanja usmrtitev in je razvijalcem neskončno nerazumljiva, dejansko ima le majhen ustrezen prostor stanj, ki jih uporabniki v praksi uporabljajo. To pomeni, da so kljub vsej zapletenosti razvijalci sposobni pridobiti ravno dovolj znanja o tem ustreznem prostoru usmrtitev in zagotoviti, da je programska oprema zanje učinkovita in zanesljiva. Potem, tudi kadar programska oprema ni učinkovita in robustna, sumim, da so uporabniki odporni na večino napak, s katerimi se srečujejo, pri iskanju rešitve ali spreminjanju ciljev glede na vedenje. Ta teorija odpornosti pojasnjuje, zakaj je programska oprema dragocena, čeprav je krhka. To ne pomeni, da odpovedi programske opreme niso pomembne: pride do hudih napak in razvijalci pogosto izvirajo iz tega, da nimajo natančne predstave o tem, kateri deli stanja prostora zapletenega programskega sistema dejansko so pomembni na tem področju. Poleg tega razvijalci pogosto nimajo orodij ali podatkov, potrebnih za to natančno znanje. Poleg tega obstaja veliko podkomponent sistemov, ki so popolnoma avtomatizirani, da jih moramo biti sposobni uradno preveriti, da preprečimo resne okvare na nižji stopnji. Obstajajo tudi pomembni pomisleki človeka v zanki, ki potrebujejo posebno pozornost, da se uredijo, zato potrebujejo metode HCI. Tako stabilni, kot je svet do krhke programske opreme, lahko in moramo narediti boljše.

V četrtek na kosilu sem si privoščil pogovor z mlajšim kolegom o svetovanju doktorskim študentom. Zastavil je odlična vprašanja, ki so mi bila odlična podlaga za razmislek o mojih praksah. Veliko sem govoril o opredelitvi kulture in moji novi strategiji pisanja vkrcanega dokumenta, ki postavlja pričakovanja. Govoril sem o psihološki varnosti kot temelju gradnje zaupanja vrednih odnosov s svojimi študenti in v svoji ekipi. Govoril sem o kritični potrebi po dejanskem uveljavljanju in modeliranju norm v svojem dokumentu o vkrcavanju, da bi okrepil kulturo laboratorija. Delil sem ideje o skupinskem združevanju študentov, da bi povečal odgovornost, raznolikost idej in pogostost povratnih informacij. Govoril sem tudi o napetosti pred natečajem, ki lahko nastanejo zaradi potrebnih publikacij, pa tudi, da se študentom da dovolj prostora za učenje in o tem, kako rešiti te napetosti z vzdrževanjem ločene niti prvih avtorskih raziskav. Najpomembneje je, da sem kolega opomnil, da se to učenje ne ustavi. Poznam starejše kolege, ki po desetletjih učenja še vedno iščejo nasvet.

V torek zvečer sem imel čudovito večerjo s Thomasom LaTozo in doktoratom. študent August Shi, v katerem smo imeli široko razpravo o temeljnih in uporabnih raziskavah programskega inženiringa, vlogi družboslovja v raziskavah programskega inženiringa in potrebi po bolj poštenih, teoretično utemeljenih poročilih osnovne predpostavke o tehničnem delu na terenu.

Magnus Frodigh, predsednik Ericssona Research, je v sredo predstavil uvodno besedilo o brezžičnih komunikacijah in 5G. Začel je z napovedovanjem hitrega spreminjanja naših digitalnih izkušenj, a tudi počasnejšega spreminjanja omrežne infrastrukture. Trdil je, da bi stabilnost standarda 5G pomenila vse vrste nove transformativne infrastrukture v IoT, vključno s komunikacijo med strojem in strojem v realnem času. Poglobil se je v podrobnosti 5G infrastrukture, kar se mi je zdelo suho in večinoma nepomembno za programsko inženirstvo, toda prepričljiva vizija, pokopana v pogovoru, je bila nepredstavljiva lestvica povezanosti med ljudmi in stroji, ki v bistvu odpravlja zamude. Magnus je trdil, da bo to prototipizacijo novih izkušenj drastično olajšalo, saj je mogoče sisteme sestaviti v celoti prek omrežnih storitev z nizko zakasnitvijo, ne pa preko namestitve strojne opreme.

Med sredo zjutraj smo se z Walterjem Tichyjem, Jamesom Herbslebom odločno pogovarjali o tem, kako preoblikovati uporabo in razvoj teorije skupnosti za raziskave programske opreme. Začeli smo z opazovanjem, kako imajo na terenu teorije, so zgolj implicitne, in če bi to izrecno nakazali, bi nas lahko spodbudili k ponovnemu premisleku o naših predpostavkah in naših raziskovalnih usmeritvah. Na primer, polje ima teorije o moči abstrakcije, predstave o nagnjenosti k napakam pri oblikovanju programskega jezika in kako razumevanje programa. Te teorije preprosto ne navajamo nazorno. James je bil tudi teoretičen in je bil odziv na naše pozive k dodatni teoriji, zato sumimo, da se je področje pripravljeno naučiti. Razmišljali smo o načinih izobraževanja skupnosti, vključno z razvojem nekaterih lahkih materialov za poučevanje novih doktorskih študentov ali zainteresiranih fakultet. Razpravljali smo o potencialni organizaciji Dagstuhla za razvoj in uporabo teh gradiv.

Chris Parnin razpravljal o kompleksnosti poučevanja.

Preostali del srede sem preživel na sestankih na progi Izobraževanje in usposabljanje programske opreme (ki ji bom sopredsedoval leta 2020, vendar se mi zdi tudi zelo pomembno in osrednjega pomena za moje interese pri izobraževanju računalništva). Ta skladba objavlja stroge, strokovno preverjene računalniške raziskave o računalniškem inženiringu. Chris Parnin je prvo sejo začel s pogovorom o uporabi velikega zapletenega izvajanja programske opreme iTrust za poučevanje programskega inženiringa. Ugotovil je, da so študenti veliko kasneje po tečaju cenili globoko zavzetost z velikim kompleksnim sistemom, vendar v tem času niso uživali v vsem. Delo z zapuščeno kodo je bilo pretirano. Tečaj so revidirali tako, da so pouk uskladili s samim projektom, kar je privedlo do veliko bolj pozitivnih stališč o tečaju (kot bi bilo treba pričakovati; študenti potrebujejo skladno pripoved o dejavnostih v razredu, da ohranijo svoje udejstvovanje). V drugem pogovoru je bilo ugotovljeno, da je aktivno gledanje videoposnetkov, v katerem učenci komentirajo vsebino in pregledujejo komentarje, povečalo sodelovanje pri gledanju videoposnetkov. Nekateri pogovori so bili osredotočeni na laboratorije, okolice in druge izkustvene učne projekte. Na splošno so te študije ugotovile, da je izkustveno učenje res težko logistično izvesti, izziv za avtentičnost in zelo težko je znati oceniti. Zdi se, da potrebujemo nekaj teorij izkustvenega učenja, da to delo organiziramo.

Reid Holmes je govoril o stvareh, ki so jih učenci uživali.

Reid Holmes je predstavil lepo longitudinalno študijo kanadskega programa izkušenj za visoko uspešne študente računalništva (dodiplomski Capstone Open Source Projects). Študija je odkrila presenetljivo pozitivne izkušnje, pri katerih so študentje zelo cenili uporabo svojega učilništva pri resničnih, novih nalogah, za resnične projekte s skupnostjo uporabnikov, obenem pa prejemali mentorstvo od pravih razvijalcev. Temen spodnji del tega dela je, kako izberemo študente: program izrecno izbere najboljše študente iz več institucij, kar se izogne ​​številnim učnim izzivom, ki bi se lahko pojavili pri manj pripravljenih študentih.

Deževni gozd Universeuma je bil res vlažen!

Sprejem v sredo je bil v Universeumu, naravoslovnem muzeju, polnem živali, rib in masivnega vlažnega deževnega gozda. Za sprejem je bil to res zanimiv kontekst, saj je bil, namesto da bi bil velik odprt prostor za pogovor, poln interaktivnih eksponatov, ki so udeležence vključevali v igro in raziskovanje. Razstave niso bile posebej vabljive ali prepričljive, vendar so bile dovolj dobre, da so sprožile vse vrste zanimivih pogovorov, ki jih verjetno ne bi imeli drugače. Udeleženci sem se pogovarjal o pošasti Gila, klopotačih, meduzeh, vzdrževanju programske opreme eksponatov, ki temeljijo na programski opremi, in širokem razponu cinizma, ki se je prelil v akademsko računalništvo.

Četrtek zjutraj sem zajtrkoval z Brendanom Murphyjem, Laurie Williams in doktoratom UW. študent Calvin Loncaric v naši hotelski zajtrk. Veliko razprav smo imeli o dveh velikih izzivih, ki sta mi draga: uskladitev formalnih sistemov, kot so programski jeziki, s človeškimi in socialnimi sistemi, ter usklajevanje statističnih sistemov, kot je strojno učenje s človeškimi in socialnimi sistemi. Po mojem mnenju sta to dva najpomembnejša velika izziva računalništva, vendar jih večina ljudi v računalništvu ignorira. Brendan je imel veliko povedati o zapletenosti poenotenja analize podatkov in strojnega učenja z resničnimi projekti, Laurie je veliko govorila o istih izzivih z računovodenjem varnosti pri razvoju programske opreme, Calvin pa je te težave obravnaval pri svojem delu sinteze podatkovnih struktur, kjer so vprašanja o razumljivosti sintetizirane kode in učljivosti njegovega jezika za specifikacije odprta vprašanja.

Fred Brooks Jr., ki razlaga zgodovino.

V četrtek dopoldne sta bila dva glavna besedila. Fred Brooks, mlajši, avtor seminarja The Mythical Man-Month o upravljanju projektov s programsko opremo, daje retrospektivo. Fred je govoril o razvoju programov, programske opreme, programskih sistemov, programskih izdelkov. Nato je programsko inženirstvo opredelil kot disciplino izdelave programskih izdelkov. Govoril je o velikih idejah v zgodovini programskega inženiringa, vključno s programi von Neumanna kot podatkovnimi in programskimi jeziki na visoki ravni, kot so COBOL in FORTRAN. V 60. letih je kriza programske opreme (izziv gradnje velikih sistemov) pripeljala do ideje o programskem inženiringu kot inženiringu. Veliko priznanje pri tem je bilo, da rast zahtevnosti projektov ni linearna. Veliko tega je privedlo do prispevkov sistemov, kot so interaktivna odpravljanja napak Toma Kilburna in operacijski sistem za deljenje časa Fernando Corbato, sistemi baz podatkov, ideje formalne verifikacije Roberta Floyda in Tonyja Hoareja ter usmeritev k predmetu Simula. V sedemdesetih letih so se pojavili podatki Davida Parnasa, abstraktni podatki Barbare Liskov, abstraktni podatki podatkov Harlan Mills in Niklaus Wirth, postopno natančnejše preverjanje kode Michaela Fagana in upravljanje programskega projekta. Barry Boehm je postavil tudi vprašanja o preverjanju zahtev in preverjanju zahtev. Zelo priporočam ACM-jev vebinar Grady Booch o zgodovini programskega inženiringa in življenjskih prispevkih Barryja Boehma.

Margaret Hamilton je delila zgodbe o programiranju glavnih glav.

Druga četrtkova jutranja govornica je bila Margaret Hamilton, ki je zamislila stavek "programsko inženirstvo". Bila je študentka matematike, ko se je odločila, da se bo na MIT razvijala za vremensko programsko opremo na LGP30 in razvila zanimanje za programsko opremo in na koncu zgradila Apollo programske sisteme, ki so dovolili ZDA pristanek na Luni. Njen govor "Jezik kot programski inženir" je govoril o velikih težavah: integracija, evolvability je težka, ponovna uporaba je težka, programska oprema pa ne. Vprašala je, zakaj smo v 50 letih tako malo napredovali? Trdila je, da jih je bilo nekaj. Prej ni bilo polja; zdaj je. Določili smo izraze. Toda v resnici je, da je programska inženirka izrazito človeško, izrazito družbeno in izrazito intelektualno delo, in še vedno se ne spopadamo z večino teh dejavnikov. Navedla je primere temeljnih izzivov HCI pri ustvarjanju interaktivnih sistemov med ljudmi, programsko opremo, napakami in odpravljanju napak in kako so bili ti ključni za pristanek na Luni. Zavedala se je, da so sistemi po naravi asinhroni, porazdeljeni in na dogodke in da morajo jeziki, ki se uporabljajo za pisanje programske opreme, to odražati. To je uravnotežila z razpravo o potrebi načrtovanja skozi arhitekturo prek večkratnih, zanesljivih vzorcev. Ponosen sem bil, ko sem v vprašanjih in vprašanjih videl prepoznavnost zgodovine skupnosti, njeno vrednost in oddaljene izvore nekaterih največjih zamisli na terenu.

Miryung Kim iz UCLA je govoril o fascinantni študiji vlog o podatkovni znanosti.

V četrtek sem vodil sejo z naslovom »Študij programskih inženirjev«, na kateri so bile štiri navdušujoče empirične študije, vključno z dvema publikacijama prve TSE, ki sta ju objavili. Prvo, "Razumevanje potreb razvijalcev po deprecijaciji kot jezikovni značilnosti" (avtor Anand Sawant v TU Delft), je odkrilo številne uporabne trende glede uporabe in zlorabe funkcij za odpravljanje, opredelilo potrebe po datumih opustitve, opozorila o resnosti in več raznolikosti opozorilnih vrst. Drugi članek, "O dihotomiji razhroščevalnega vedenja med programerji" (avtor Moritz Beller iz TU Delft), je odkril, da se v praksi orodja za odpravljanje napak redko uporabljajo, da "printf debugging" ostaja prevladujoč, znanje o orodjih za odpravljanje napak pa je precej nizka. Prvi članek iz revije, „Merjenje razumevanja programa: obsežna terenska študija s strokovnjaki“ (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing in Shanping Li), je ugotovil, da razvijalci porabijo večino svojega časa za razumevanje kode, da uporabljajo spletne brskalnike in urejevalnike za razumevanje kode in da več razvijalcev ima izkušenj, manj časa porabi za razumevanje. Zadnji članek na seji, "Podatkovni znanstveniki v programskih skupinah: najsodobnejši izzivi in ​​izzivi" (Miryung Kim, Thomas Zimmermann, Robert DeLine in Andrew Begel), je opravil anketo o 793 strokovnih znanstvenikih in ugotovil, da je res zanimiva nabor 9 vrst vlog s področja znanosti o podatkih: polimati, evangelisti podatkov, pripravljavci podatkov, oblikovalci podatkov, oblikovalci platform, lunjači različnih stopenj in vpogledni akterji, ki so podatke razlagali in uporabljali za sprejemanje odločitev. Ta bogata dekonstrukcija ali drugačne vloge se zdijo resnično močne za obveščanje o izobraževanju o podatkih.

Zadnja seja v četrtek je bila praznovanje 50 let programskega inženiringa. Brian Randell je dal retrospektivo o prvem programskem inženiringu leta 1968. Brian je govoril o tem, kako malo je bilo že izumljeno računalništvo; brez interneta, brez omrežij, brez ponovne uporabe. In vendar so bila vsa vprašanja: testiranje, pravilnost, upravljanje itd. Brian je razlikoval med programiranjem in programskim inženiringom, tako da je programsko inženirstvo opredelil kot "razvoj za več oseb", ki ga imajo več oseb. "(Ne spomni se, da bi to rekel , vendar David Parnas vztraja, da je). Zaključil je, da je področje zraslo bolj, kot je zorelo, in spraševal se je, ali smo ga naredili dovolj daleč, da se imenujemo inženirska disciplina, ter zatiral skupnost, da je izumil še en jezik in še eno tehniko.

Brajanovemu govoru je sledil panel štirih prvotnih udeležencev konference iz leta 1968. Eno vprašanje, o katerem so razpravljali, je bilo, kaj obžalujejo v zadnjih petdesetih letih. Izpostavili so pomanjkanje osredotočenosti na inženiring zahtev, pomanjkanje pozornosti na dezinformacije, pomanjkanje pozornosti na vzdrževanje programske opreme. Razočarani so bili v 60. letih in zdaj so razočarani. Nekateri strokovnjaki so bili navdušeni nad formalnimi metodami, vendar so bili razočarani nad njihovo pomanjkljivostjo. Razočarani so bili tudi nad tem, kako malo smo odkrili, kako usmerjati oblikovalske odločitve glede na kakovost programske opreme. Na splošno pa se je zdelo malo konsenza glede tega, ali so se stvari izboljšale ali ne. Gotovo gradimo bolj zapletene stvari, a so kaj boljše, bolj na čas?

Ribe, ovitek in diaprojekcije

Četrtkov večerni banket je bil v ladjedelnici in je bil čuden okus dejavnosti. Obstajala je jedilnica v slogu banketov, oder na prostem z doktoratom. študenti, ki pojejo rockovsko glasbo, in švedska zasedba, ki med večerjo pojejo pesmi 90-ih in 2000-ih, medtem ko je voditeljica slavila skupnost inženirjev programske opreme in na oder povabila različne organizatorje konferenc, da se zahvalijo. Med večerjo se je predvajala diaprojekcija z vsemi vrstami poljubnih logotipov programskega izdelka iz zgodovine računalništva, občasni retrospektivni video z intervjuji svetilk programske opreme. Bilo je čudaško, neokusno in dezorijentirajoče, še posebej, ko je kup udeležencev izklesal kotiček prostora za prireditve, da bi zaplesali.

Programska zabava plesne zabave!Robert McClure, eden od udeležencev konference zveze NATO leta 1968.

V petek zjutraj sem v četrtek našel enega od panelistov iz četrtkove menedžmenta, Roberta McClureja, ki je med odmorom sedel sam in tako sem se odločil za začetek pogovora. Bil je eden od prvotnih udeležencev konference leta 1968 in aktiven vodja misli v industriji, ki se zavzema za napredek. Vprašal sem ga, kaj se je spremenilo v 50 letih, kaj ni in kakšen je njegov pojem napredka. O številnih temeljnih vprašanjih v programskem inženiringu smo imeli zanimiv in širok pogovor. Začel je z razpravo o nekaterih kritičnih razlikah med zasnovo programske opreme (ki zahteva razumevanje težave in njenega konteksta), inženirskim dizajnom (za katerega je treba skrbno določiti rešitev) in inženiringom (kar je čisto izvajanje te specifikacije). Robert je primerjal programsko opremo z drugimi inženirskimi disciplinami, zato sem ga vprašal, kaj verjame, da so temeljne razlike, če sploh. Predpostavil je, da gre za stopnjo. Špekuliral sem, da je bila kritična razlika stopnja, v katero se lahko oblikovalec ali inženirja prepričata v razumevanje težave ali specifikacije; razumevanje mesta, na katerem gradite most, se opira na naravoslovne vede, ki so predvidljive do stopnje, ki ne velja za človeške, družbene in organizacijske sisteme, za katere je programska oprema običajno zasnovana. To pomanjkanje samozavesti ustvarja potrebo po oblikovanju prototipov, povratnih informacij in evoluciji, ki niso tako potrebne za druge inženirske discipline (in tudi niso tako izvedljive). Govorili smo tudi o izobrazbi, ki je potrebna za vse te veščine, in hitrosti sprememb, ki jih je pričakoval. V zadnjih 50 letih je pričakoval veliko več sprememb, kot jih je opazoval, in špekuliral je, da je človeška narava veliko bolj odporna na spremembe, kot je kdajkoli verjel. Predlagal sem, da gre morda le za neuspešno učinkovito izobraževanje v kombinaciji s hitrim povečanjem števila razvijalcev s približno 10.000 v letu 1968 na 30 milijonov v letu 2018. Spodbudil me je, da spodbudim svoja pričakovanja glede sprememb; Rekel sem mu, da sem kot zaposlen profesor naslednjih 40 let v njem in bom potrpežljiv.

Brian Randell, zgodovinar programske opreme.

Po naključju sem našel tudi Briana Randella, četrdesetletnega petdesetletnega govornika programskega inženiringa, ki sedi sam. Vprašal sem ga, zakaj verjame, da je 2. Natova konferenca tako razočarala in kakšen vpliv je imel na prihodnja desetletja raziskav in prakse programskega inženiringa. Trdil je, da je bila velika težava v tem, da so v 2. letniku obstajali delitve ob dveh. Prvič, nekateri so si zamislili svet, v katerem bi lahko poslali popolnoma pokvarjeno brezplačno programsko opremo, drugi pa so verjeli, da to ni mogoče in bi morali načrtovati. Poleg druge dimenzije so bili nekateri zainteresirani za dekonstrukcijo problema programskega inženiringa, drugi pa za orodja, tehnike in druge rešitve, za katere so verjeli, da bi jih lahko izboljšali. Udeleženci, razdeljeni v teh vrsticah, se niso mogli ujeti. Idealisti in realisti niso vedeli, kako sodelovati in problematično porabljeni preveč časa kritizirajo rešitve ljudi, osredotočenih na rešitve, medtem ko so ljudje, osredotočeni na rešitve, odporni na povratne informacije. Predlagal sem, da veliko teh oddelkov še danes obstaja v sodobnih raziskavah programskega inženiringa, in se Brianu zahvalil, da je pomagal razsvetliti zgodovinski izvor teh oddelkov.

Ivar je svojo zgodbo odprl z zgodbo.

Ivar Jacobson, glavni sodelavec UML in racionalnega enotnega procesa, je spregovoril z naslovom: "50 let programskega inženiringa, kaj zdaj?" Začel je z anekdoto o enem od svojih prvih projektov programskega inženiringa, kjer je moral priznati , o inženiringu programske opreme ni vedel nič. In vendar je še vedno vodil enega najuspešnejših švedskih izdelkov v zgodovini. Njegova interpretacija programske uspešnosti je na koncu posledica poslovnih modelov in razvijalcev, ne programske opreme in ne procesa. Njegovo stališče je, da je po 50 letih še vedno več kot obrt, kot inženirska disciplina. Pravzaprav v zgodovini trdi, da nas moda veliko bolj poganja kot znanost: objektna orientacija, UML, CMMI, Agile in vse, kar je naslednje, so bile in bodo vse modne. Ivarjev argument je bil, da so bile vse metode vojne odvračanje. Prava težava je po mnenju Ivarja v tem, da so metode res kompozicije praks, metode pa monolitne in ujete v zaporih, ki jih varujejo guruji. Po Ivarjevem mnenju je to nezrelo in neumno.

Njegovo priporočilo je bilo osredotočiti se na iskanje skupne podlage za metode, modularizirati metode in proste prakse od metod. Govoril je o organu za standardizacijo, ki je predvideval pojem praks, ki imajo dejavnosti, ki imajo nekatera merila uspešnosti, in delovne izdelke, ki izhajajo iz dejavnosti, ki so ocenjene v skladu s temi merili uspešnosti. Njegova ključna točka pa je, da vse to od razvijalcev zahteva, da so kompetentni za vse te stvari. Merila uspeha segajo do potreb strank, rešitve, ki jo izdelujejo, in ekipe, ki jo bo dosegla. Predstavil je še nekaj podrobnosti o stanjih, ki se skozi njegovo model dogajajo. To, kar mi je opisal, zveni kot znanstvena teorija procesa in skupek procesnih idej, ki izhajajo iz te teorije; nekaj, kar je treba preizkusiti in izpopolniti, ne evangelij. Na koncu jo je dejansko poimenoval opisna teorija in raziskovalce pozval, naj jo še naprej razvijejo v teorijo prediktivne in razlage.

Takoj po Ivarjevem pogovoru sem opravil svoj nagovor ICSE o najbolj vplivnih nagradah. Sredi sej za podelitev nagrad sem lahko rekel, da so ljudje utrujeni in pripravljeni na konec tedna. Moj govor je imel mračen, odsevni ton, vendar spodbuden ton, in čeprav je tišina po pogovoru bila oglušujoča, je bilo klepetanje na Twitterju poživljajoče in je pokazalo skupnost, ki resnično verjame in ceni, kar sem morala povedati, in je lačna napotkov o kako narediti.

Andreas začne svoj nagradni nagovor

Andreas Zeller je spregovoril takoj za mano, ko je prejel svojo raziskovalno nagrado SIGSOFT. Povedal je tri zgodbe o svoji karieri, vse osredotočene na vpliv. Prva zgodba je bila o njegovem prvem projektu in predstavitvi, v katerem je prispeval rešitev za iskanje problema. Nezadovoljen s povratnimi informacijami se je uprl, tako da se je osredotočil na odpravljalec napak GNU DDD, ki je imel dejanski praktični vpliv. Njegova prva epifanija je bila, da je iskanje resničnih težav tako nujno, a tudi odličen način vpliva. Njegova druga zgodba je bila o preprostosti. Nekdo na konferenci je bil zgrožen, da je bila njegova ideja o odpravljanju napak tako preprosta. To je privedlo do sindroma prevare, občutka intelektualne manjvrednosti. Vendar je sčasoma spoznal, da je preprostost moč; zapletenost je bila neuspeh. Njegova zadnja zgodba je bila o delu, ki ga je začel s Tomom Zimmermannom na skladiščih rudarske programske opreme. Opazil je, da strahovi pred rezultati njihovega zgodnjega dela preprosto niso bili pomembni, saj je bilo dejstvo novo. Inovacija je namenjena preučevanju temnih neraziskanih, a pomembnih delov sveta. Andreas je na koncu trdil, da je edino, kar je resnično pomembno, vpliv. Končal je z navdihujočim pozivom, naj uresničujemo svoje sanje in vztrajamo.

Zbogom od Göteborga je izziv povzeti vse, kar sem se naučil na letošnjem ICSE. Toda poskusimo vseeno:

  • Na koncu smo vsi v tej skupnosti, da izboljšujemo programsko opremo. Osredotočimo se na to in ne na kratkoročne meritve.
  • Potrebujemo večje ideje, najverjetneje v obliki teorij, da nas usmerjajo in usmerjajo naš vpliv.
  • Za dosego zgornjih ciljev moramo razmišljati o ustreznosti, ne o objavi.
  • Človeške dejavnike v inženiringu programske opreme ignoriramo.

To so lekcije, ki jih mora na koncu ponotranjiti vsak član naše skupnosti. Minilo je že 50 let, odkar smo spoznali njihov pomen, in šele začenjamo jih jemati resno.