ICSE 2018 matkaraportti: 50 vuotta ohjelmistosuunnittelua

Suurin osa kaikista 40 ICSE-kokouksen johtavista puheenjohtajista ja ohjelmatuoleista.

Ohjelmistotekniikan tutkimusala on tänä vuonna 50 vuotta vanha; suurin, vanhin ja paras ohjelmistosuunnittelukonferenssi, kansainvälinen ohjelmistotekniikan konferenssi, on 40 vuotta vanha. Tämän vuoden konferenssi oli suuri mahdollisuus yhteisölle katsoa taaksepäin viimeisen puolen vuosisadan tutkimukseen ja kysyä: ”Mitä olemme oppineet? Mitä olemme unohtaneet? Mitä meiltä puuttuu? ”Vietin viikon Göteborgissa, Ruotsissa, tarttumalla tähän kysymykseen pohtiessaan monia oivallisia avainsanoja ja keskusteluja, jotka vastasivat näihin kysymyksiin, mutta jaoin myös omat ajatukseni siitä, miten edetä kahden kutsutun keskustelun kautta.

Aloittaakseni ensimmäisen koko päiväni, annoin avauspuheenvuoron Mining Software -varastoissa.

Aloitin aikani ICSE: ssä antaen ICPC 2018: lla ja MSR 2018: lla yhteisen avainnoteen monitieteellisen työn ja teorian tarpeesta ohjelmistotekniikan tutkimuksessa, käyttämällä ymmärrykseen ja kaivostoimintaan keskittyviä yhteisöjä esimerkkeinä näille suuremmille pisteille. Kirjoitin puheestani edellisessä viestissä, tiivistäen argumenttini. Puheenvuoroni jälkeen ja koko konferenssin aikana kävin todella mielenkiintoisia keskusteluja molempien vanhempien tutkijoiden kanssa, jotka kamppailivat ymmärtääkseni teorian tarkoittamia, mutta myös uuden Ph.D. Opiskelijat kiehtovat teoriamahdollisuuksista tehdä työstään vaikuttavampaa. Minulla oli hieno ryhmäkeskustelu useiden CMU: n jatko-opiskelijoiden kanssa siitä, mikä teoria on, miltä se näyttää, kuinka se voi muuttaa tekemämme tutkimukset ja miten se voi tehdä tuloksistamme syvällisempiä. Puhuin myös Adobe Analytics -insinöörin kanssa, joka yritti saada sisäisiä analytiikkatyökaluja. Se oli kiehtova tilaisuus yrittää vaikuttaa siihen, kuinka seuraavan sukupolven tutkijat ja insinöörit sisällyttävät teorian teokseen, mutta se sai minut ihmettelemään, kuinka opettaa teoriakäyttöä tehokkaasti.

Vietin maanantaina osan ajastaan ​​MSR: n ja ICPC: n istunnoissa kuulemalla viimeisimpiä tutkimuksia virhesanomien havainnoinnista, suunnittelumallien ymmärtämisestä ja muista pyrkimyksistä tutkia ymmärrettävyyttä. Yksi paperi toisti arvioinnin 121 koodiin liittyvästä monimutkaisuusmittarista nähdäkseen, olivatko ne korreloivia kehittäjien itse ilmoittaman ymmärrettävyyskokemuksen kanssa, ja havaitsivat, että pituus ja muuttujien nimet ennustivat yhdessä kehittäjien arvioita. Näissä pienemmissä rinnakkain järjestetyissä konferensseissa on todella järkevää tietojen käyttöä, joissa esitetään todella pakottavia kysymyksiä ymmärryksen ja kaivostoiminnan risteyksessä. Kuten totin aloituspuheenvuorossani, he todella tarvitsevat ymmärtämistä koskevaa teoriaa, mutta heidän löytämänsä mallit ovat hyvä perusta näiden teorioiden kehittämiselle.

Maanantaina iltapäivällä kävin niittaamalla keskustelun Tim Menziesin kanssa syvien ja matalien mallien suhteellisista eduista. Hän vastasi pääpuheenvuoroni osittain yllätyksenä siitä, etten ollut tehnyt syvällisempää kritiikkiä arkistojen kaivosyhteisöstä, mutta myös siitä, että en ollut tunnustanut yksinkertaisten, matalien mallien hämmästyttävää voimaa optimoida ja skaalata kaikenlaisia ​​ohjelmistopäätöksiä engineering. Hänen väitteensä oli lähinnä se, että joissakin tapauksissa tai ehkä monissa tapauksissa meidän ei tarvitse selittää miksi työkalut, järjestelmät tai prosessit toimivat, niiden on vain toimittava. Olemme hajauttaneet erimielisyydet lopulta päätellen, että tarvitsemme todennäköisesti kaikenlaista syvyyttä koskevia malleja (teorioista selittämättömiin lakeihin mieletömiin, mutta tarkkoihin ennustemoottoreihin). Tällainen monimuotoisuus on todennäköisesti merkki terveestä akateemisesta keskustelusta.

MSR-juhla Göteborgin maailmankulttuurimuseossa.

Maanantai-iltana järjestettiin juhla Mining Software Repositories -konferenssille. Minulla oli runsaasti keskusteluja Mei Nagappanin, Andy Zaidmanin ja Michael Godfreyn kanssa. Puhuimme kaikesta hallussapidosta ja ylennyksestä, CS: n laaja-alaisesta oppimisesta, henkilökohtaisesta historiastamme ohjelmoinnin oppimisesta ja roolistamme portinvartijana CS: n opettamisessa. Minulle tällaiset keskustelut ovat akateemisen verkostoitumisen syvä sisältö: ne ovat keskusteluja elämästämme, ideoistamme ja miten ne ovat vuorovaikutuksessa.

Abram puhui asteittaisen tieteellisen kehityksen tarpeesta.

Tiistaiaamuna Abram Hindle piti vaikuttavimman paperipalkintopuhelun paperistaan: ”Mitä suuret sitoumukset kertovat meille? Suurien toimeksiantojen taksonominen tutkimus? ”Tässä tutkimuksessa oli merkitystä siinä, että se oli yksi ensimmäisistä papereista, jonka tarkoituksena ei ollut vain edistää kaivostekniikoita, vaan tosiasiallisesti kysyä arkistojen sisällöstä siirtämällä alaa kohti tieteellisempiä kysymyksiä ohjelmistoista tekniikka, ei vain kaivosteollisuus. Se, mikä mielestäni oli mielenkiintoista teoksesta, oli se, kuinka hyvin sitä arvioitiin tieteellisesti: se väitti vahvasti, että poikkeavuudet ovat tärkeitä eivätkä tiedostamattomia ja että suuret sitoutuneet ulkopuoliset olivat todella kriittisiä indikaattoreita ohjelmistojen kehityksen luonteesta. Se keskittyi myös ainutlaatuisesti toimeksiantojen yksityiskohtaiseen sisältöanalyysiin, joka oli (ja on edelleen) harvinainen menetelmä kaikissa tiedon louhinnan tutkimuksissa. Abram esitti myös vakuuttavan väitteen, jonka mukaan asiakirjojen hylkääminen siitä, että heillä ei ole välittömästi toteutettavissa olevia tuloksia, heikentää tiedettä ja siten tulevaisuuttamme ja on ristiriidassa stipendin kanssa. Kysymyksissä ja vastauksissa Abram esitti joitain mielenkiintoisia näkökohtia tutkimuksen taloudellisuudesta ja siitä, kuinka se voi vääristää mitä kysymyksiä käsittelemme ja minkä syvän tieteellisen tutkimuksen me sallimme.

Tauon aikana Lutz Prechelt esitti minulle kiehtovan kysymyksen: miksi ohjelmistot rakennetaan, otetaan käyttöön ja käytetään tuottavasti huolimatta siitä, että ohjelmistot ovat niin monimutkaisia ​​ja kehittäjät ovat niin valmistautumattomia? Heijastelin hetkeksi ja jaoin suurenmoisen teorian. Selitin, että vaikka ohjelmistoilla on käytännöllisesti katsoen loputon tilatilojen toteuttamistila ja että kehittäjät ovat äärettömästi ymmärrettäviä, niillä on käytännössä vain pieni merkityksellinen tila tilaa, joita käyttäjät käyttävät käytännössä. Tämä tarkoittaa, että kaikesta tästä monimutkaisuudesta huolimatta kehittäjät kykenevät hankkimaan juuri tarpeeksi tietoa tästä asiaankuuluvasta täytäntöönpanotilasta ja varmistamaan, että ohjelmisto on heille tehokas ja kestävä. Silloin, vaikka ohjelmisto ei olisi tehokas ja kestävä, epäilen, että käyttäjät ovat sietäviä suurimmalle osalle havaitsemistaan ​​virheistä, etsivät kiertotapoja tai muuttavat tavoitteitaan käyttäytymisen perusteella. Tämä joustavuuden teoria selittää, miksi ohjelmisto on arvokas huolimatta haurasta. Tämä ei tarkoita, että ohjelmistovirheillä ei ole väliä: vakavia virheitä on, ja usein ne johtuvat siitä, että kehittäjillä ei ole tarkkaa käsitystä siitä, mitkä monimutkaisen ohjelmistojärjestelmän tilatilat tosiasiallisesti vaikuttavat kentälle. Lisäksi kehittäjillä ei usein ole työkaluja tai tietoja, jotka ovat tarpeen tämän tarkan tiedon saamiseksi. Lisäksi on olemassa monia järjestelmien alakomponentteja, jotka ovat täysin automatisoituja ja jotka meidän on pystyttävä virallisesti todentamaan loppupään vakavien vikojen estämiseksi. On myös merkittäviä ihmisen silmukassa tekemiä näkökohtia, jotka oikeutensa saamiseksi vaativat erityistä erityistä huomiota ja vaativat HCI-menetelmiä. Joten niin joustava kuin maailma on hauras ohjelmisto, voimme ja meidän on tehtävä paremmin.

Otin tauon tiistaina lounaalla keskustelemaan niittaamalla nuoremman kollegan kanssa jatko-opiskelijoiden neuvonnasta. Hän kysyi erinomaisia ​​kysymyksiä, jotka loivat minulle hyvän perustan pohtia käytäntöjäni. Puhuin paljon kulttuurin määrittelystä ja uudesta strategiastani kirjoittaa aluksella oleva asiakirja, joka asettaa odotukset. Puhuin psykologisesta turvallisuudesta luotettavien suhteiden rakentamisen perustana opiskelijoilleni ja ryhmäni kanssa. Puhuin kriittisestä tarpeesta tosiasiallisesti valvoa ja mallintaa mukana olevassa asiakirjassani normeja laboratorion kulttuurin vahvistamiseksi. Jaoin ideoita opiskelijoiden ryhmittelystä yhdessä vastuullisuuden, ideoiden monimuotoisuuden ja palautteen tiheyden lisäämiseksi. Keskustelin myös ennakkojännityksistä, joita voi aiheutua julkaisujen tarpeesta, mutta myös tarpeesta antaa opiskelijoille tilaa oppia, ja kuinka ratkaista nämä jännitteet ylläpitämällä erillinen säde ensimmäisestä kirjoitetusta tutkimuksesta. Tärkeintä on, että muistutin kollegalleni, että tämä oppiminen ei lopu. Tunnen vanhempia kollegoita, jotka etsivät edelleen neuvoja vuosikymmenien oppimisen jälkeen.

Minulla oli upea illallinen tiistai-iltana Thomas LaTozan ja tohtorin kanssa. opiskelija August Shi, jossa kävimme laajan keskustelun perus- ja sovellusohjelmistotekniikan tutkimuksesta, yhteiskuntatieteen roolista ohjelmistotekniikan tutkimuksessa ja rehellisempien, teoreettisesti perusteltujen tilien tarpeesta alan teknisen työn taustalla olevissa oletuksissa.

Ericsson Researchin puheenjohtaja Magnus Frodigh piti keskiviikkona avauspuheenvuoron langattomasta viestinnästä ja 5G: stä. Hän aloitti ennustamalla nopean muutosvauhdin digitaalisissa kokemuksissamme, mutta myös hitaamman muutosvauhdin verkkoinfrastruktuurissa. Hän väitti, että 5G-standardin vakaus olisi kaikkea kaikenlaista IoT: n uutta muuttuvaa infrastruktuuria, mukaan lukien reaaliaikainen koneiden välinen viestintä. Hän sukeli syvällisesti 5G-infrastruktuurin yksityiskohtiin, mikä oli mielestäni kuiva ja enimmäkseen merkityksetöntä ohjelmistosuunnittelulle, mutta keskustelun sisälle haudattu pakottava visio oli ihmisten ja koneiden välinen käsittämätön yhteys, joka liittyy olennaisesti latenssin poistamiseen. Magnus väitti, että tämä tekee uusien kokemusten prototyyppien muuttamisen dramaattisesti helpommaksi, koska järjestelmät voidaan rakentaa kokonaan vähän viiveellä varustetuilla verkkopalveluilla eikä laitteisto-asennuksilla.

Keskiviikkoaamun aikana Walter Tichyn, James Herbslebin kanssa kävimme tuloksellisessa keskustelussa siitä, miten ohjelmistotekniikan tutkimusyhteisön käyttö ja teorian kehittäminen muutetaan. Aloitimme tarkkailemalla, kuinka kentällä on teorioita, ne ovat vain implisiittisiä, ja jos ne tehdään eksplisiittisiksi, ne voivat saada meidät harkitsemaan oletuksiamme ja tutkimussuuntaamme. Esimerkiksi kentällä on teorioita abstraktion voimasta, käsityksistä virheprosenssista ohjelmointikielisuunnittelussa ja kuinka ohjelman ymmärtäminen toimii. Emme vain tee näitä teorioita selväksi. James oli antanut avainsanan myös teoriasta, ja hän ja minä olimme molemmat saaneet lämpimät vastaukset vaatimuksiin lisää teoriaa, joten epäilemme, että kenttä on valmis oppimaan. Pohdimme tapoja kouluttaa yhteisöä, mukaan lukien joidenkin kevyiden materiaalien kehittäminen uusien jatko-opiskelijoiden tai kiinnostuneiden tiedekuntien opettamiseksi. Keskustelemme mahdollisesta Dagstuhlin järjestämisestä näiden materiaalien kehittämiseksi ja käyttöönottamiseksi.

Chris Parnin keskustelee monimutkaisesta opetuksen monimutkaisuudesta.

Vietin loput keskiviikosta osallistuessani ohjelmistotekniikan koulutusradalla (jonka puheenjohtajana toimin vuonna 2020, mutta mielestäni se on myös melko tärkeä ja keskeinen kiinnostukseni laskennallisen koulutuksen suhteen). Tämä kappale julkaisee tiukan, vertaisarvioidun laskennallisen koulutuksen tutkimuksen ohjelmistosuunnittelusta. Chris Parnin aloitti ensimmäisen istunnon puhumalla iTrustin, suuren monimutkaisen ohjelmistototeutuksen, käyttämisestä ohjelmistotekniikan opettamiseen. Hän huomasi, että opiskelijat arvostivat paljon myöhemmin kurssin jälkeen syvää sitoutumista suureen monimutkaiseen järjestelmään, mutta he eivät nauttinneet siitä kaikesta kurssin aikana. Vanhan koodin kanssa työskenteleminen oli ylivoimaista. He muuttivat kurssia mukauttamalla luokan aktiviteetit itse projektiin, mikä johti paljon positiivisempiin tunteisiin kurssista (kuten pitäisi odottaa; opiskelijat tarvitsevat johdonmukaista kerrontaa luokan aktiviteetteista sitoutumisen ylläpitämiseksi). Toisessa keskustelussa havaittiin, että aktiivinen videoiden katselu, jossa oppijat kommentoivat sisältöä ja arvioivat kommentteja, lisäsivät kiinnostusta videon katseluun. Jotkut keskusteluissa keskityttiin laboratorioihin, huippukiviin ja muihin kokemuksellisiin oppimisprojekteihin. Yleensä näissä tutkimuksissa havaittiin, että kokemuksellista oppimista on todella vaikea suorittaa logistisesti, haastavaa tehdä aitoja ja erittäin vaikea tietää miten arvioida. Kuulostaa siltä, ​​että tarvitsemme joitain kokemuksellisen oppimisen teorioita tämän työn organisoimiseksi.

Reid Holmes keskustelee asioista, joista opiskelijat nauttivat oppimisesta.

Reid Holmes esitteli hienon pitkittäistutkimuksen Kanadan kokeellisesta oppimisohjelmasta korkean suorituskyvyn tietotekniikan opiskelijoille (perustutkintoa tarjoavat Capstone Open Source Projects). Tutkimuksessa löydettiin hämmästyttävän positiivisia kokemuksia, joiden avulla opiskelijat arvostivat luokkaviestinnän soveltamista todellisiin, uusiin tehtäviin, todellisiin hankkeisiin käyttäjien yhteisön kanssa samaan aikaan mentoroimalla oikeilta kehittäjiltä. Työn pimeä osa on se, miten opiskelijat valitaan: Ohjelma valitsee nimenomaisesti parhaat oppilaat useista oppilaitoksista, mikä välttää monia oppimishaasteita, joita voi syntyä vähemmän valmistautuneiden opiskelijoiden kohdalla.

Universumin sademetsä oli todella kostea!

Keskiviikkoiltana vastaanotto oli Universeumissa, luonnontieteellisessä museossa, joka oli täynnä eläimiä, kaloja ja massiivista kosteaa sademetsää. Se oli todella mielenkiintoinen vastaanottoyhteys, koska sen sijaan, että se olisi suuri avoin tapahtumatila keskustelulle, se oli täynnä interaktiivisia näyttelyitä, jotka houkuttelivat osallistujia leikin ja tutkimuksen ympärille. Näyttelyt eivät olleet erityisen kutsuvia tai houkuttelevia, mutta ne olivat riittävän hyviä, että ne käynnistivät kaikenlaisia ​​mielenkiintoisia keskusteluja, joita meillä ei todennäköisesti olisi ollut muuten. Puhuin osallistujille Gila-hirviöistä, kalkkarokäärmeistä, meduusasta, ohjelmistopohjaisten näyttelyiden ohjelmistojen ylläpidosta ja monesta kyynisyydestä, joka on päässyt akateemiseen tietotekniikkaan.

Torstai aamu aamiaisin aamiaisen Brendan Murphyn, Laurie Williamsin ja UW Ph.D: n kanssa. opiskelija Calvin Loncaric hotellin aamiaishuoneessa. Meillä oli laaja keskustelu kahdesta sydämelleni kiinnostavasta suuresta haasteesta: muodollisten järjestelmien, kuten ohjelmointikielten, sovittaminen ihmisen ja sosiaalisten järjestelmien kanssa ja tilastollisten järjestelmien, kuten koneoppimisen, yhteensovittaminen ihmisen ja sosiaalisten järjestelmien kanssa. Mielestäni nämä ovat kaksi tärkeintä tietotekniikan suurta haastetta, ja silti suurin osa tietotekniikan ihmisistä sivuuttaa ne. Brendanilla oli paljon sanottavaa tietojen analysoinnin ja koneoppimisen yhdistämisestä todellisten projektien kanssa, Laurie puhui paljon samoista haasteista tietoturvan kirjanpidon kanssa ohjelmistokehityksessä, ja Calvin tarkasteli näitä ongelmia omassa tietorakenteiden synteesin työssään, missä syntetisoidun koodin ymmärrettävyyden ja hänen määritelmäkielensä opittavuuden huomioon ottaminen ovat avoimia kysymyksiä.

Fred Brooks Jr., tulkitsee historiaa.

Torstaiaamuna oli kaksi avainsanoja. Fred Brooks, Jr, kirjoittanut ohjelmistoprojektihallinnan seminaarin The Mythical Man-Month, esittelee retrospektiivin. Fred puhui ohjelmien, ohjelmistojen, ohjelmistojärjestelmien, ohjelmistotuotteiden kehityksestä. Sitten hän määritteli ohjelmistosuunnittelun ohjelmistotuotteiden valmistuksen osa-alueeksi. Hän puhui suurista ideoista ohjelmistotuotannon historiassa, mukaan lukien von Neumannin ohjelmat datana ja korkean tason ohjelmointikielet, kuten COBOL ja FORTRAN. 60-luvulla ohjelmistokriisi (suurten järjestelmien rakentamisen haaste) johti ajatukseen ohjelmistosuunnittelusta tekniikkaksi. Suuri tunnustus tässä oli, että projektien monimutkaisuuden kasvu ei ollut lineaarista. Suuri osa tästä johti järjestelmiin osallistumiseen, kuten Tom Kilburnin vuorovaikutteiseen virheenkorjaukseen ja Fernando Corbaton aikajakoiseen käyttöjärjestelmään, tietokantajärjestelmiin, Robert Floydin ja Tony Hoaren ideoihin muodollisesta varmennuksesta ja Simulan objektisuuntautuneisuuteen. 70-luvulla, David Parnasin tietojen piilottaminen, Barbara Liskovin abstraktit tietotyypit, Harlan Millsin ja Niklaus Wirthin asteittainen hienosäätö, Michael Faganin kooditarkastukset ja ohjelmistoprojektien hallinta kaikki nousivat esiin. Barry Boehm kysyi myös vaatimuksista ja vaatimusten validoinnista. Hän suositteli Grady Boochin ACM-verkkoseminaaria ohjelmistotuotannon historiasta ja Barry Boehmin elinaikanaan osallistumista.

Margaret Hamilton jakaa tarinoita suurten keskusyksiköiden ohjelmoinnista.

Toisena torstainaamuna pääpuhujana toimi Margaret Hamilton, joka kuvasi ilmausta ”ohjelmistosuunnittelu.” Hän oli matematiikan opiskelija, kun hän päätti harjoitella MIT: n kehittämässä LGP30-sääohjelmistoa ja kehitti kiinnostusta ohjelmistoihin, ja lopulta hän rakensi Apollon. ohjelmistojärjestelmät, jotka antoivat Yhdysvaltojen laskeutua kuuhun. Hänen puheessaan ”Kieli ohjelmistosuunnittelijana” puhuttiin suurista ongelmista: integroituminen, kehityskelpoisuus on vaikeaa, uudelleenkäyttö on vaikeaa ja ohjelmisto epäonnistuu. Hän kysyi, miksi olemme saavuttaneet niin vähän edistystä 50 vuodessa? Hän väitti, että joitain on ollut. Aiempaa kenttää ei ollut; nyt on. Olemme määritelleet termit. Mutta todellisuus on, että ohjelmistosuunnittelu on selvästi inhimillistä, selvästi sosiaalista ja selvästi älyllistä työtä, eikä meitä vieläkään voida kohdata useimmissa näistä tekijöistä. Hän antoi esimerkkejä HCI: n perustavanlaatuisista haasteista, jotka aiheutuvat vuorovaikutteisten järjestelmien luomisesta ihmisten välillä, ohjelmistoista, virheistä ja virheiden palautuksesta, ja kuinka nämä olivat keskeisiä kuun laskeutumiselle. Hän tajusi, että järjestelmät ovat luonteeltaan asynkronisia, hajautettuja ja tapahtumavetoisia, ja että ohjelmistojen kirjoittamiseen käytettävien kielten tulisi heijastaa tätä. Hän tasapainotti tätä keskustelua tarpeesta suunnitella arkkitehtuurin kautta uudelleenkäytettävien ja luotettavien kuvioiden avulla. Olin ylpeä nähdessäni kysymyksissä ja vastauksissa, että yhteisö tunnustaa historian, sen arvon ja kentän suurimpien ideoiden kaukaisen alkuperän.

Miryung Kim UCLA: sta puhui kiehtovasta tutkimuksesta datatieteen rooleista.

Torstaina johdin “Studying Software Engineers” -istuntoa, jossa oli neljä kiehtovaa empiiristä tutkimusta, mukaan lukien kaksi lehden ensimmäistä TSE-julkaisua. Ensimmäinen, ”Kehittäjien tarpeiden ymmärtäminen vanhenemisesta kielen ominaisuutena” (kirjoittanut Anand Sawant, TU Delft) löysi monia hyödyllisiä suuntauksia poisto-ominaisuuksien käyttöön ja väärinkäyttöön, yksilöi tarpeet vanhentumispäiville, vakavuusvaroitukset ja lisää monimuotoisuutta varoitustyypeistä. Toisessa artikkelissa ”Ohjelmoijien virheenkorjauksen dikotomialta” (kirjoittanut Moritz Beller, TU Delft) havaittiin, että käytännössä virheenkorjaustyökaluja käytetään harvoin, että ”printf-virheenkorjaus” on hallitseva ja virheenkorjaustyökalujen tuntemus on melko matala. Istunnon ensimmäisen lehden, ”Ohjelman ymmärtämisen mittaus: laaja-alainen tutkimus ammattilaisten kanssa” (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing ja Shanping Li), havaittiin, että kehittäjät viettävät suurimman osan ajastaan ​​ymmärtääkseen -koodin, että he käyttävät selaimia ja muokkausohjelmia koodin ymmärtämiseen ja että mitä enemmän kokemusta kehittäjällä on, sitä vähemmän aikaa he käyttävät ymmärtämiseen. Istunnon viimeinen artikkeli, ”Data Scientists in Software Teams: the Art of the Art and Challenges” (Miryung Kim, Thomas Zimmermann, Robert DeLine ja Andrew Begel), teki tutkimuksen 793 ammattitutkijasta ja löysi todella mielenkiintoisen joukko 9 tietotekniikan tyyppiä: polymaatit, tiedon evankelistat, tiedon valmistelijat, tiedon muotoilijat, alustan rakentajat, eriasteiset kohderyhmät ja näkemystoimijat, jotka tulkitsivat tietoa ja käyttivät sitä päätöksentekoon. Tämä rikas dekonstruktio tai erilaiset roolit vaikuttavat todella tehokkaalta tietotekniikan koulutuksen järjestämiselle.

Viimeinen torstaina pidetty juhla oli juhla 50 vuoden ohjelmistotuotannolle. Brian Randell antoi retrospektiivin ensimmäisestä ohjelmistosuunnittelusta jo vuonna 1968. Brian puhui siitä, kuinka vähän tietojenkäsittelystä oli vielä keksitty; ei Internetiä, ei verkkoja, ei uudelleenkäyttöä. Ja silti kaikki asiat olivat siellä: testaus, oikeellisuus, hallinta jne. Brian erotti ohjelmoinnin ja ohjelmistosuunnittelun määrittelemällä ohjelmistosuunnittelun "monihenkilökohtaisten ohjelmien monihenkisen kehityksen". (Hän ei muista sanoneen tätä , mutta David Parnas vaatii tekevänsä). Hän päätteli, että kenttä on kasvanut enemmän kuin se on kypsynyt, ja kyseenalaisti, olemmeko saavuttaneet riittävän pitkälle tullaksemme nimeltään tekniikan kurinalaisuuden, ja valitsimme yhteisöä keksimään vielä toisen kielen ja vielä yhden tekniikan.

Brianin puhetta seurasi paneeli, joka koostui neljästä alkuperäisestä osallistujasta vuoden 1968 konferenssissa. Yksi heidän keskustelemansa kysymys oli, mitä he pahoittelivat viimeisen 50 vuoden aikana. He herättivät keskittymisen puutetta vaatimusten suunnitteluun, väärien tietojen huomiotta jättämistä ja huomiota ohjelmistohuoltoon. He olivat pettyneet takaisin 60-luvulla ja he ovat pettyneet nyt. Jotkut paneelista olivat innostuneita muodollisista menetelmistä, mutta pettyivät hyväksymisensä puuttumiseen. He olivat pettyneitä myös siitä, kuinka vähän olemme löytäneet siitä, kuinka ohjata suunnittelupäätöksiä suhteessa ohjelmistoominaisuuksiin. Kaiken kaikkiaan näytti kuitenkin olevan vähän yksimielisyyttä siitä, ovatko asiat parantuneet vai eivät. Rakennamme varmasti monimutkaisempia asioita, mutta ovatko parempia, ajoissa?

Kalat, kansi nauha ja diaesitykset

Torstai-iltana järjestetty juhla oli telakalla ja oli omituista aktiviteettia. Oli bankettityyppinen ateria, ulkona vaihe Ph.D. Opiskelijat laulavat rockmusiikkia ja ruotsalainen cover-yhtye, joka laulaa 90- ja 2000-luvun pop-kappaleita illallisen aikana, kun taas emäntä juhlii ohjelmistotekniikkayhteisöä ja kutsui erilaiset konferenssijärjestäjät lavalle sanomaan kiitoksen. Illallisen aikana diaesitys pelataan kaikenlaisilla mielivaltaisilla ohjelmistotuotelogoilla laskennan historiasta, toisinaan takautuvalla videolla ohjelmistotekniikan valaisimien haastatteluilla. Se oli hauska, hajoavaa ja häiritsevää, varsinkin kun joukko osallistujia veti ulos tapahtumatilan nurkkaan tanssimaan.

Ohjelmistotekniikan tanssijuhlat!Robert McClure, yksi vuoden 1968 Naton konferenssin osallistujista.

Perjantaiaamuna löysin yhden torstaina esittämästä paneelista Robert McCluren, joka istui tauon aikana yksin, ja päätin aloittaa keskustelun. Hän oli yksi vuoden 1968 konferenssin alkuperäisistä osallistujista ja aktiivinen teollisuuden ajattelija, joka puolusti kehitystä. Kysyin häneltä siitä, mikä on muuttunut 50 vuodessa, mikä ei ole, ja mikä on hänen käsitys etenemisestä. Meillä oli kiehtova, laaja keskustelu monista ohjelmistosuunnittelun peruskysymyksistä. Hän aloitti keskustelemalla eräistä kriittisistä eroista suunnittelussa, mitä ohjelmisto tekee (mikä vaatii ongelman ja sen kontekstin ymmärtämistä), suunnitteluprosessissa (joka vaatii ratkaisun huolellista määrittämistä) ja suunnittelussa (joka on kyseisen määritelmän puhdas toteutus). Robert vertasi ohjelmistosuunnittelua muihin tekniikan aloihin, joten kysyin häneltä, mitkä hänen mielestä olivat mahdollisia perustavanlaatuisia eroja. Hän ehdotti, että siinä oli kysymys asteesta. Arvelin, että kriittinen ero oli siinä, missä määrin suunnittelija tai suunnittelija voi olla varma ymmärtäessään ongelmaa tai eritelmää; Sivun, jolle silta rakennetaan, ymmärtäminen perustuu luonnontieteisiin, jotka ovat ennustettavissa siinä määrin, että ne eivät ole totta inhimillisissä, sosiaalisissa ja organisaatiojärjestelmissä, joille ohjelmisto on tyypillisesti suunniteltu. Tämä luottamuksen puute luo tarpeen prototyyppien laatimiseen, palautteeseen ja evoluutioon, joka ei ole tarpeellista muille tekniikan aloille (eikä myöskään niin toteutettavissa). Puhuimme myös kaikkien näiden taitojen välttämättömästä koulutuksesta ja hänen odottamiensa muutosvauhdista. Hän odotti paljon enemmän muutosta viimeisen 50 vuoden aikana kuin hän on havainnut, ja arvasi, että ihmisen luonto on paljon muutoskestävämpi kuin hän koskaan uskoi. Ehdotin, että se saattaa olla vain tehokkaan koulutuksen epäonnistuminen yhdistettynä kehittäjien määrän nopeaan kasvuun noin 10 000: sta vuonna 1968 30 miljoonaan vuonna 2018. Hän rohkaisi minua hillitsemään muutos-odotuksiani; Sanoin hänelle, että palkattuna professorina olin siinä seuraavan 40 vuoden ajan ja olisin kärsivällinen.

Brian Randell, ohjelmistotekniikan historioitsija.

Satunnaisesti löysin myös Brian Randellin, torstain 50-vuotisen ohjelmistotekniikan pääpuhujan, joka istuu yksin. Kysyin häneltä, miksi hän uskoi toisen Naton konferenssin olevan niin pettymys, ja kuinka hänen mielestään sillä oli seuraavien vuosikymmenien ajan ohjelmistotekniikan tutkimukseen ja käytäntöön. Hän väitti, että suurin osa ongelmasta oli se, että toisena vuonna oli jakautumisia kahdella. Ensinnäkin jotkut ihmiset kuvasivat maailmaa, jossa voimme lähettää täysin virheellisiä ilmaisia ​​ohjelmistoja, ja toiset uskoivat, että tällainen asia ei ole mahdollista ja meidän pitäisi suunnitella sitä. Toisessa ulottuvuudessa jotkut ihmiset olivat kiinnostuneita ohjelmistosuunnittelun ongelman purkamisesta ja toiset kiinnostivat työkaluista, tekniikoista ja muista ratkaisuista, joiden uskoivat voivan parantaa sitä. Näiden linjojen mukaan jakautuneet osallistujat eivät vain päässeet toimeen. Idealistit ja realistit eivät tienneet yhteistyötä ja ongelmakeskeiset käyttivät liikaa aikaa kritisoidakseen ratkaisukeskeisiä ihmisiä, kun taas ratkaisukeskeiset ihmiset vastustivat palautetta. Ehdotin, että monet näistä jakautumista esiintyvät edelleen nykyaikaisessa ohjelmistotekniikan tutkimuksessa, ja kiitin Briania näiden kahden jaon historiallisen alkuperän valaisemisesta.

Ivar avasi avainsanansa tarinalla.

Ivar Jacobson, merkittävä UML: n ja Rational Unified -prosessin avustaja, piti puheen nimeltä ”50 vuotta ohjelmistosuunnittelua, niin mitä nyt?” Hän aloitti anekdootin yhdestä ensimmäisistä ohjelmistosuunnitteluprojektistaan, jossa hänen täytyi myöntää , hän ei tiennyt mitään ohjelmistosuunnittelusta. Ja silti hän johti yhä historian menestyneimpiä ruotsalaisia ​​tuotteita. Hänen tulkintansa ohjelmiston menestyksestä johtuu viime kädessä liiketoimintamalleista ja kehittäjistä, ei ohjelmistoista, eikä prosessista. Hänen näkemyksensä mukaan 50 vuoden kuluttua se on edelleen enemmän käsityötä kuin tekniikan tiedettä. Itse asiassa historiassa hän väittää, että meitä ajaa paljon enemmän muoti kuin tiede: esinekeskeisyys, UML, CMMI, ketterä ja mikä seuraavaksi tapahtuu, olivat ja tulevat olemaan kaikenlaisia. Ivar väitti, että kaikki menetelmissodat ovat olleet häiriötekijöitä. Ivarin mukaan todellinen ongelma on, että menetelmät ovat todella harjoitteluyhdistelmiä ja menetelmät ovat monoliittisia ja loukussa gurujien vartioimissa vankiloissa. Ivarin mielestä tämä on epäkypsää ja typerää.

Hänen suosituksensa oli keskittyä menetelmiin liittyvän yhteisen kentän löytämiseen, menetelmien modulointiin ja menetelmien vapaisiin käytäntöihin. Hän puhui standardointielimestä, joka kuvasi käsitteen käytännöistä, joilla on toimintaa, jolla on joitain menestyskriteereitä, ja työtuotteista, jotka ovat peräisin toiminnoista, joita arvioidaan näiden menestyskriteerien perusteella. Hänen keskeinen kohta on kuitenkin, että kaikki nämä vaativat kehittäjiä olemaan osaamista kaikissa näissä asioissa. Menestyskriteerit sopivat yhteen asiakkaan tarpeiden, valmistettavan ratkaisun ja joukkueen kanssa sen saavuttamiseksi. Hän esitti useita lisätietoja valtioista, joita yksi käy läpi mallillaan. Se, mitä hän kuvaili, kuulostaa tieteelliseltä prosessiteorialta ja tästä teorialta johdetulle prosessideoille; jotain testattavaa ja parannettavaa, ei evankeliumia. Loppujen lopuksi hän kutsui sitä itse asiassa kuvaavaksi teoriaksi ja kehotti tutkijoita kehittämään sitä edelleen ennustavaksi ja selittäväksi teooriaksi.

Heti Ivarin puheen jälkeen pidasin ICSE: n vaikutusvaltaisimman paperipalkinnon. Palkintoistunnon keskellä voin kertoa, että ihmiset olivat väsyneitä ja valmiita viikon loppuun. Puheellani oli somber, heijastava, mutta rohkaiseva sävy, ja vaikka hiljaisuus keskustelun jälkeen oli ahdistava, Twitterissä oleva chattailusta tuli virkistävä, osoittaen yhteisöä, joka todella uskoo ja arvostaa sitä, mitä minun oli sanottava, ja on nälkäinen opastusta varten kuinka tehdä se.

Andreas aloittaa palkintopuhelunsa

Andreas Zeller puhui heti minun jälkeenni saatuaan SIGSOFT-tutkimuspalkinnon. Hän kertoi urastaan ​​kolme tarinaa, jotka kaikki keskittyivät vaikutteisiin. Ensimmäinen tarina oli hänen ensimmäisestä projektistaan ​​ja esityksestään, jossa hän oli antanut ratkaisun etsimään ongelmaa. Pettyneenä palautteeseen, hän palasi keskittymällä GNU DDD -vastaanottimeen, jolla oli todellinen käytännöllinen vaikutus. Hänen ensimmäinen lopullisuutensa oli, että todellisten ongelmien löytäminen oli niin välttämätöntä, mutta myös loistava tapa vaikuttaa. Hänen toinen tarinansa koski yksinkertaisuutta. Joku konferenssissa oli inhoava, että hänen ajatuksensa Delta-virheenkorjauksesta oli niin yksinkertainen. Tämä johti huijareiden oireyhtymään, henkisen ala-arvon tunteeseen. Mutta hän tajusi ajan myötä, että yksinkertaisuus oli voimaa; monimutkaisuus oli epäonnistuminen. Hänen viimeinen tarinansa koski työtä, jonka hän aloitti Tom Zimmermannin kanssa kaivosohjelmistojen arkistoista. Hän huomautti, että pelkoilla heidän varhaisen työn tuloksista ei yksinkertaisesti ollut merkitystä, koska työ oli uusi. Innovaatiolla tarkoitetaan pimeästi tutkimatta, mutta asiaankuuluvia maailman osia. Viime kädessä Andreas väitti, että ainoa asia, jolla on todella merkitystä, on vaikutus. Hän päättyi inspiroivalla kehotuksella jatkaa unelmiesamme ja jatkaa.

Sanoen hyvästi Göteborgiin, on haastavaa tehdä yhteenveto kaikesta, mitä olen oppinut tämän vuoden ICSE: ssä. Yritetään kuitenkin muuten:

  • Viime kädessä olemme kaikki tässä yhteisössä parantamaan ohjelmistoja. Keskitytään siihen, ei lyhytaikaisiin mittareihin.
  • Tarvitsemme isompia ideoita, todennäköisesti teorioiden muodossa, jotka opastavat meitä ja vaikuttavat vaikutuksemme.
  • Meidän on ajateltava osuvuutta, ei julkaisemista, yllä olevien tavoitteiden saavuttamiseksi.
  • Ohitamme inhimilliset tekijät ohjelmistosuunnittelussa vaarassa.

Nämä ovat oppitunnit, jotka jokaisen yhteisömme jäsenen on lopulta sisäistettävä. On kulunut 50 vuotta siitä, kun olemme tajanneet heidän merkityksensä, ja olemme vasta alkamassa suhtautua heihin vakavasti.