ICSE 2018 utazási jelentés: 50 éves szoftverfejlesztés

Az ICSE mind a 40 ülésén az általános elnökök és a programszékek többsége.

A szoftverfejlesztési kutatás területe idén 50 éves; a legnagyobb, legrégebbi és legjobb szoftverfejlesztési konferencia, a Szoftverfejlesztés Nemzetközi Konferenciája 40 éves. Az idei konferencia nagyszerű esélyt jelentett a közösség számára, hogy visszatekintsen az elmúlt fél évszázados kutatásokra és kérdezzék: „Mit tanultak? Mit felejtettünk el? Mi hiányzik? ”A héten a svédországi Göteborgban töltöttem, hogy megvitassam ezt a kérdést, gondolkodva a sok észrevehető vitaindító tárgyaláson és beszélgetésen, amelyek megválaszoltam ezeket a kérdéseket, de megosztottam saját gondolataimat arról is, hogyan lehet előrehaladni két meghívott beszélgetésen keresztül.

Az első teljes napom elindítása érdekében adtam a nyitó vitaindítót a Bányászati ​​Szoftvertárban.

Az ICSE-nál indítottam az idejemet, amelyben az ICPC 2018 és az MSR 2018 közös vitaindító tárgyát adta az interdiszciplináris munka és az elmélet szigorú szükségességéről a szoftverfejlesztés kutatásában, felhasználva a megértésre és a bányászatra összpontosító közösségeket mint példákat ezekre a nagyobb pontokra. Az előző bejegyzésben írtam a beszédemről, összefoglalva érveimet. A beszélgetésem után és a konferencia során igazán érdekes beszélgetéseket folytattam mindkét vezető kutatóval, akik megpróbáltak megérteni, hogy mit értek az elmélet alatt, de új Ph.D. a hallgatókat elbűvöli az a lehetőség, hogy az elmélet munkájának hatásosabbá váljon. Nagyszerű csoportos beszélgetés volt a CMU több doktoranduszával arról, hogy mi az elmélet, hogyan néz ki, hogyan tudja átalakítani az általunk elvégzett tanulmányokat, és hogyan lehet mélyebb eredményeket eredményezni. Beszéltem egy Adobe Analytics mérnökkel is, aki küzdött az analitikai eszközök belső átvevőinek beszerzéséhez. Izgalmas lehetőség volt arra, hogy megpróbáljuk befolyásolni, hogy a kutatók és mérnökök következő generációja miként illesztheti be az elméletet a munkába, ám arra késztette, hogy vajon hogyan lehet hatékonyan tanítani az elmélet használatát.

Hétfőn időm egy részét az MSR és az ICPC ülésein töltöttem, hallva a hibaüzenetek észlelésének, a tervezési minták megértésének és a megérthetőség vizsgálata céljából tett legújabb kutatásoknak. Az egyik cikk megismételte a 121 kódokkal kapcsolatos összetettség-mutató értékelését, hogy kiderüljön-e azok összefüggésben a fejlesztők által az önértékelhetőséggel kapcsolatos tapasztalatok alapján, megállapítva, hogy a hosszúság és a változónevek együttesen előrejelzik a fejlesztők értékelését. Vannak valóban okos adatok felhasználási lehetőségei ezekben a kisebb, egymás mellett elhelyezkedő konferenciákon, amelyek igazán vonzó kérdéseket tesznek fel a megértés és a bányászat metszéspontjában. Amint azt a beszédemben megjegyeztem, valóban szükségük van a megértés elméletére, ám az általuk talált minták jó alapot nyújtanak ezeknek az elméleteknek a fejlesztéséhez.

Hétfő délután szexuális beszélgetésem volt Tim Menzies-kel a mély és a sekély modellek relatív előnyeiről. Részben meglepő módon válaszolt a vitaindító kérdésre, hogy nem fogalmaztam meg mélyebben a tároló bányászati ​​közösségét, hanem azt is, hogy nem ismerem el az egyszerű, sekély modellek lenyűgöző erejét, hogy optimalizálják és méretezzék a szoftverekben alkalmazott mindenféle döntést. mérnöki. Az érvelése alapvetően az volt, hogy bizonyos esetekben, vagy talán sok esetben, nem kell magyaráznunk, hogy miért működnek az eszközök, rendszerek vagy folyamatok, csak működniük kell. Kihúztottuk a nézeteltéréseket, és végül arra a következtetésre jutottunk, hogy valószínűleg mindenféle mélységű modellekre van szükség (az elméletektől a megmagyarázhatatlan törvényekig az elméletlen, de pontos prediktív motorokig). Ez a sokféleség valószínűleg az egészséges tudományos diskurzus jele.

Az MSR bankett a göteborgi világkultúra múzeumában.

Hétfő este volt bankett a Mining Software Repositories konferencián. Gazdag párbeszéd volt Mei Nagappan, Andy Zaidman és Michael Godfrey között. Mindent beszéltünk a megbízatástól és a promóciótól, a CS szintű tanulásig, a személyes történetünket a programozáshoz való tanulás körül, és kapuőrként betöltött szerepünkről a CS oktatásában. Számomra az ilyen beszélgetések az akadémiai hálózatépítés mély lényege: beszélgetések az életünkről, ötleteinkről és arról, hogy miként működnek együtt.

Ábrám a fokozatos tudományos haladás szükségességéről beszélt.

Kedd reggel Ábrám Hindle beszédet mondott a legbefolyásosabb papírdíjról: „Mit mondanak nekünk a nagyvállalatok? A nagy bizottságok taxonómiai tanulmánya? ”Ebben a cikkben az volt a jelentős, hogy az egyik első cikk volt, amely nemcsak a bányászati ​​technikákat fejlesztette elő, hanem valójában kérdést tett fel a tárolók tartalmával kapcsolatban, és a mezőt a szoftverrel kapcsolatos tudományos kérdések felé mozgatta. mérnöki, nem csak a bányászati ​​technikák. Ami igazán érdekesnek találta a munkát, az az volt, hogy mennyire vélekedett tudományosan: erősen azt állította, hogy a túlmutatók fontosak és nem tudatlanok, és hogy a nagy elkötelezettségű outlierek valóban kritikus mutatók voltak a szoftverfejlesztés természetéről. Egyedülállóan a kötelezettségvállalások részletes tartalomelemzésére összpontosított, amely minden adatbányászati ​​kutatás során ritka módszer volt (és ma is). Ábrám azt is megkérdőjelezte, hogy az okmányok elutasítása azért, mert nem állnak rendelkezésre azonnal meghozható eredmények, meghökkenti tudományunkat és következésképpen jövőnket, és ellentétes azzal, amit az ösztöndíj szól. A kérdések és válaszok során Ábrám néhány betekintést nyert a kutatás közgazdaságtanáról és arról, hogy hogyan tudja megcsavarni az általunk feltett kérdéseket és a tudományos vizsgálatok mélységét.

A szünet alatt Lutz Prechelt izgalmas kérdést tett fel nekem: miért van annak ellenére, hogy a szoftver annyira összetett és a fejlesztők annyira felkészületlenek, hogy ezt a szoftvert építeni, alkalmazni és hatékonyan használják? Egy pillanatig elgondolkodtam, és megosztottam nagyszerű elméletemmel. Magyarázatom az volt, hogy annak ellenére, hogy a végrehajtás ténylegesen végtelen állapotterülettel rendelkezik, és a fejlesztők végtelenül érthetetlenek, valójában csak egy kis, releváns állapottér van a felhasználók által a gyakorlatban használt állapotokban. Ez azt jelenti, hogy a komplexitás ellenére a fejlesztők csak annyit tudnak megszerezni a végrehajtás ezen releváns tereiről, és biztosítják a szoftver hatékonyságát és megbízhatóságát számukra. Ezután még akkor is, ha a szoftver nem hatékony és robusztus, gyanítom, hogy a felhasználók rugalmasak a felmerült hibák nagy része ellen, megoldást találnak, vagy céljaikat a viselkedés alapján megváltoztatják. Ez a rugalmasság elmélete magyarázza, miért értékes a szoftver a törékeny ellenére. Ez nem azt jelenti, hogy a szoftverhibák nem számítanak: vannak súlyos hibák, és gyakran azok a fejlesztők, amelyeknek nincs pontos elképzelésük arról, hogy a komplex szoftverrendszer állapotterületének mely részei relevánsak a területen. Ráadásul a fejlesztők gyakran nem rendelkeznek az ehhez a pontos tudáshoz szükséges eszközökkel vagy adatokkal. Sőt, számos olyan rendszerelemek alkotják tisztán automatizált rendszereket, amelyeket formálisan ellenőriznünk kell a későbbi súlyos hibák megelőzése érdekében. Vannak olyan jelentős „emberi hurokban” megfontolások is, amelyekre különös figyelmet kell fordítani a helyrehozáshoz, és HCI-módszereket igényelnek. Annak érdekében, hogy a világ törékeny legyen a törékeny szoftverekre, jobban tudunk és kell tennünk.

Kedd ebédszünetet tartottam, hogy szerencsés beszélgetésbe kerüljünk egy junior kollégával a doktoranduszok tanácsadásáról. Kiváló kérdéseket tett fel, amelyek nagyszerű alapot jelentettek számomra a gyakorlatomat tükrözni. Sokat beszélt a kultúra meghatározásáról és az új stratégiámról, amikor egy fedélzeti dokumentumot írok, amely meghatározza az elvárásokat. Beszéltem a pszichológiai biztonságról, mint a bizalmi kapcsolatok kiépítésének alapjáról a hallgatóimmal és a csapatommal. Beszéltem a fedélzeti dokumentumban szereplő normák tényleges érvényesítésének és modellezésének kritikus szükségességéről, hogy megerősítsem laboratóriumom kultúráját. Ötleteket osztottam meg a hallgatók együttes csoportosítása érdekében, hogy növeljük az elszámoltathatóságot, az ötletek sokféleségét és a visszajelzések gyakoriságát. Megbeszéltem azokat a túllépési feszültségeket is, amelyek a kiadványok szükségességéből adódhatnak, de lehetőséget kell biztosítani a hallgatók számára a tanulásra is, és hogyan lehet ezeket a feszültségeket az első szerzői kutatás külön szálának fenntartásával megoldani. A legfontosabb, hogy emlékeztettem ezt a kollégát, hogy ez a tanulás nem áll meg. Ismerek olyan idősebb kollégákat, akik évtizedes tanulás után továbbra is tanácsot kérnek.

Kedden este csodálatos vacsorát vettem Thomas LaToza-val és Ph.D.-vel. Shi hallgató, amelyben széles körű vitát folytattak az alap- és alkalmazott szoftverfejlesztési kutatásokról, a társadalomtudomány szerepéről a szoftverfejlesztés kutatásában, valamint az őszintebb, elméletileg megalapozottabb beszámolók szükségességéről a terület műszaki munkájának alapjául szolgáló feltételezésekről.

Magnus Frodigh, az Ericsson Research elnöke szerdán nyitott vitaindító előadást adott a vezeték nélküli kommunikációról és az 5G-ről. Először a digitális tapasztalatok gyors változásának előrejelzésével, de a hálózati infrastruktúra változásának lassabb előrejelzésével is megjósolta. Azt állította, hogy az 5G-szabvány stabilitása mindenféle új transzformációs infrastruktúrára vonatkozik az IoT-ben, ideértve a valós idejű gépi kommunikációt is. Mélyen belemerült az 5G-es infrastruktúra részleteibe, amelyet száraznak és leginkább a szoftverfejlesztés szempontjából irrelevánsnak találtam, de a beszélgetésbe eltemetett kényszerítő látomás az emberek és gépek közötti összekapcsolhatóság elképzelhetetlen mértéke volt, amely lényegében kiküszöböli a késleltetést. Magnus azt állította, hogy ez drámaian megkönnyíti az új élmények prototípusának készítését, mivel a rendszereket teljes egészében alacsony késleltetésű hálózati szolgáltatásokkal lehet összeállítani, nem pedig a hardverek telepítésén keresztül.

A szerda reggeli szünetben Walter Tichy, James Herbsleb és termékeny beszélgetésünk során arról beszéltünk, hogy miként lehet átalakítani a szoftverfejlesztési kutatóközösség használatát és az elmélet fejlesztését. Megkezdtük annak megfigyelését, hogy a térség miként rendelkezik elméletekkel, ezek csak implicitek, és ha explicit módon fogalmazunk meg, akkor arra késztethetünk minket, hogy újragondoljuk feltételezéseinket és kutatási irányainkat. Például, a mezőnek elméletei vannak az absztrakció hatalmáról, a hibarányosság fogalmáról a programozási nyelvtervezésben és arról, hogyan működik a programmegértés. Csak nem tesszük világossá ezeket az elméleteket. James kulcsfontosságú véleményt adott az elméletről is, és én és mindkettőnkkel meleg válaszokat kaptunk a további elmélet iránti felhívásokra, tehát feltételezzük, hogy a terület készen áll a tanulásra. Megvizsgáltuk a közösség oktatásának módjait, ideértve néhány könnyű anyag kifejlesztését új doktori hallgatók vagy érdeklődő oktatók oktatására. Megbeszéljük a Dagstuhl esetleges megszervezését ezen anyagok fejlesztése és telepítése céljából.

Chris Parnin a komplex tanítási komplexumról beszélget.

Szerda hátralévő részét a szoftverfejlesztési oktatási és képzési pályán ültem (amelyet 2020-ban társelnökem leszek, de azt is gondolom, hogy nagyon fontos, és központi jelentőségű a számítástechnikai oktatás iránti érdeklődésem során). Ez a szám szigorú, szakértő által felülvizsgált számítástechnikai oktatási kutatásokat tesz közzé a szoftverfejlesztésről. Chris Parnin az első ülésen elindította egy beszédet az iTrust használatáról, amely egy nagy, komplex szoftver implementáció, a szoftverfejlesztés tanítására. Megállapította, hogy a hallgatók sokkal később a tanfolyam után nagyra értékelték a mély elkötelezettséget egy nagy komplex rendszerrel, ám a tanfolyam alatt nem élvezték mindezt. A régi kóddal való munka lenyűgöző volt. A tanfolyamot úgy módosították, hogy az osztálytevékenységeket maga a projekthez igazította, ami sokkal pozitívabb érzelmekhez vezetett a kurzus vonatkozásában (amire számíthatunk; a hallgatóknak koherens narratívára van szükségük az osztálytevékenységek körül az elkötelezettségük fenntartásához). Egy másik beszéd szerint az aktív videónézés, amelyben a tanulók megjegyzéseket fűznek a tartalomhoz és felülvizsgálják a megnövekedett videofelvételeket. Néhány beszélgetés a laborokra, a kövekre és más tapasztalati tanulási projektekre összpontosított. Ezek a tanulmányok általánosságban azt mutatták, hogy a tapasztalati tanulást logisztikailag nagyon nehéz végrehajtani, kihívást jelent hitelesítéséhez, és nagyon nehéz megérteni, hogyan kell értékelni. Úgy tűnik, hogy a munka megszervezéséhez szükségünk lesz néhány tapasztalati elméletre.

Reid Holmes megvitatja azokat a dolgokat, amelyeket a hallgatók élvezték a tanulásban.

Reid Holmes egy hosszú, longitudinális tanulmányt nyújtott be a kanadai tapasztalati tanulási programról a nagy teljesítményű informatika hallgatók számára (egyetemi Capstone nyílt forráskódú projektek). A tanulmány meglepően pozitív tapasztalatokat fedez fel a hallgatókkal, akik nagyra értékelik az osztálytermi ismeretek valódi, újszerű feladatokhoz való alkalmazását a felhasználói közösséggel folytatott valós projektekben, miközben mentorálást kapnak az igazi fejlesztőktől. Ennek a munkának az a sötét alapja, hogy a hallgatókat hogyan választják ki: a program kifejezetten kiválasztja a több intézmény legjobb hallgatóit, ezáltal elkerülhető a tanulási kihívások sokasága, amelyek a kevésbé felkészült hallgatókkal felmerülhetnek.

Az Universeum esőerdője nagyon nedves volt!

A szerda esti fogadás az Universeumban volt, egy természettudományi múzeum tele volt állatokkal, halakkal és hatalmas nedves esőerdőkkel. Nagyon érdekes kontextus volt a fogadás számára, mivel ahelyett, hogy egy nagy, nyitott beszélgetési helyiség lett volna, tele volt interaktív kiállítással, amely a résztvevőket játék és felfedezés körül vonzotta. A kiállítások nem voltak különösebben meghívóak és nem vonzóak, de elég jók voltak, hogy mindenféle érdekes beszélgetést kiválthassanak, aminek egyébként valószínűleg nem lett volnaünk. Beszéltem a résztvevőkkel a Gila szörnyekről, csörgőkígyókról, medúzákról, a szoftver alapú kiállítások szoftver karbantartásáról és a cinizmus széles skálájáról, amely bekerült az akadémiai számítástechnikába.

Csütörtök reggel reggeliztem Brendan Murphy, Laurie Williams és UW Ph.D-vel. Calvin Loncaric hallgató a szálloda reggelizőhelyén. Széles körű vitánkkal folytak két, a szívemmel kapcsolatos nagy kihívásról: a formális rendszerek, például a programozási nyelvek összehangolása az emberi és társadalmi rendszerekkel, és a statisztikai rendszerek, például a gépi tanulás összeegyeztetése az emberi és társadalmi rendszerekkel. Véleményem szerint ez a számítástechnika két legfontosabb kihívása, és mégis a számítástechnika legtöbbje figyelmen kívül hagyja őket. Brendannek nagyon sokat kellett mondania az adatok elemzésének és a gépi tanulásnak a valós projektekkel való egyesítésének bonyolultságáról, Laurie sokat beszélt ugyanazon kihívásokról, amelyek a szoftverfejlesztés biztonságának elszámolásával kapcsolatosak, és Calvin ezeket a problémákat az adatszerkezet-szintézis saját munkájában vizsgálta, ahol a szintetizált kód érthetőségének és a specifikációs nyelv megtanulhatóságának megfontolása nyitott kérdés.

János Fred Brooks, a történelem értelmezése.

Két csütörtök reggeli vita volt. Fred Brooks, Jr., a The Mythical Man-hónap szeminárium szerzője a szoftverprojektek menedzseléséről, retrospektív képet ad. Fred beszélt a programok, szoftverek, szoftver rendszerek, szoftvertermékek fejlődéséről. Ezután a szoftverfejlesztést a szoftvertermékek gyártásának tudományává határozta meg. Beszélt a szoftverfejlesztés történetének nagy ötletéről, ideértve von Neumann programjait adatként és magas szintű programozási nyelveket, mint például a COBOL és a FORTRAN. A 60-as években a szoftverválság (a nagy rendszerek kiépítésének kihívása) a szoftverfejlesztés mint mérnöki ötlethez vezette. A nagy elismerés az volt, hogy a projektek összetettségének növekedése nem volt lineáris. Ennek nagy része hozzájárult a rendszerekhez, például Tom Kilburn interaktív hibakereséséhez és Fernando Corbato időmegosztó operációs rendszeréhez, adatbázis-rendszerekhez, Robert Floyd és Tony Hoare hivatalos igazolásának ötleteihez és Simula objektumorientációjához. A 70-es években David Parnas információs rejtőztetése, Lisbar Barbara elvont adattípusai, Harlan Mills és Niklaus Wirth fokozatos finomítása, Michael Fagan kódvizsgálatai és a szoftverprojekt menedzsment jöttek létre. Barry Boehm kérdéseket is feltett a követelményekkel és a követelmények érvényesítésével kapcsolatban. Nagyon ajánlotta Grady Booch ACM webinarját a szoftverfejlesztés történetéről és Barry Boehm életében nyújtott hozzájárulásait.

Margaret Hamilton megosztja a mainframe-ek programozási történeteit.

A második csütörtök reggelt főszólam Margaret Hamilton volt, aki elképzelte a „szoftverfejlesztés” kifejezést. Matematikai hallgató volt, amikor úgy döntött, hogy gyakornokként dolgozik az MIT-ben az LGP30 időjárási szoftverek fejlesztésében, és érdeklődést mutatott a szoftverek iránt, és végül felépítette az Apollo programot. szoftver rendszerek, amelyek lehetővé tették, hogy az Egyesült Államok a földre szálljon. „A nyelv mint szoftvermérnök” című beszéde a nagy problémákról beszélt: az integráció, a fejleszthetőség nehéz, az újrafelhasználás nehéz, és a szoftver nem sikerült. Azt kérdezte, miért történt ilyen kevés előrelépés 50 év alatt? Azt állította, hogy volt valami. Korábban nem volt mező; most van. Meghatároztuk a kifejezéseket. A valóság azonban az, hogy a szoftverfejlesztés kifejezetten emberi, határozottan társadalmi és kifejezetten intellektuális munka, és még mindig nem vagyunk megbirkózva ezen tényezők legtöbbjével. Példákat mutatott az emberek közötti interaktív rendszerek létrehozása, a szoftverek, a hibák és a hibajavítás alapvető HCI-kihívásaira, és ezek miként voltak a Holdra történő leszállás szempontjából. Rájött, hogy a rendszerek aszinkron, elosztott és eseményvezérelt természetűek, és hogy a szoftverek írásához használt nyelveknek tükrözniük kell ezt. Ezt kiemeli azzal, hogy megvitatja az építkezésen keresztüli tervezés szükségességét az újrafelhasználható, megbízható mintákon keresztül. Büszke voltam arra, hogy a kérdések és válaszok során felismerte a közösség történelmének elismerését, annak értékét és a terület legnagyobb ötletének távoli eredetét.

Miryung Kim (UCLA) az adattudomány szerepének lenyűgöző tanulmányáról beszélt.

Csütörtökön a „Studying Software Engineers” című ülés elnöke volt, amely négy lenyűgöző empirikus tanulmányt tartalmazott, köztük két folyóirat első TSE publikációt. Az első, „A fejlesztők igényeinek megértése az amortizáció mint a nyelv jellemzője” (szerzője Anand Sawant, a TU Delft) sok hasznos tendenciát fedezett fel az értékcsökkenési funkciók használatával és visszaélésével kapcsolatban, meghatározva az elavulás dátumainak igényét, a súlyossági figyelmeztetéseket és a sokféleséget. figyelmeztető típusok. A „A programozók közötti hibakeresés dichotómiájáról” című cikk (Moritz Beller, a TU Delft szerzője) felfedezte, hogy a gyakorlatban a hibakeresési eszközöket ritkán használják, hogy a „printf hibakeresés” továbbra is domináns, és a hibakeresési eszközök ismerete meglehetősen alacsony. A „Program átfogóságának mérése: nagyszabású terepi tanulmány szakemberekkel” (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing és Shanping Li) ülésén megjelent első folyóiratcikk megállapította, hogy a fejlesztők idejük nagy részét megértik. kódot, hogy böngészőket és szerkesztőket használnak a kód megértéséhez, és minél több tapasztalattal rendelkezik a fejlesztő, annál kevesebb időt fordítanak a megértésre. Az ülés legutóbbi, „Adattudósok a szoftvercsapatokban: A technika állása és kihívások” (Miryung Kim, Thomas Zimmermann, Robert DeLine és Andrew Begel) 793 professzionális adattudós kutatójának felmérését készítették, és igazán érdekesnek találták. 9 típusú adattudományi szerepkör: poliamidok, adatlevangelistek, adatgyűjtők, adatformázók, platformkészítők, különféle fokú mozgatók és betekintést nyújtó szereplők, akik az adatokat értelmezték és felhasználták a döntések meghozatalára. Ez a gazdag dekonstrukció vagy különböző szerepek valóban erőteljesnek tűnnek az adattudományi oktatás tájékoztatása szempontjából.

Az utolsó csütörtök a szoftverfejlesztés 50 éves évfordulójának ünnepe volt. Brian Randell 1968-ban retrospektív képet adott az első szoftverfejlesztésről. Brian beszélt arról, hogy még mindig kevés feltalálásra került a számítástechnika; nincs internet, nincs hálózat, nincs újrafelhasználás. És mégis, minden kérdés ott volt: tesztelés, helyesség, menedzsment stb. Brian megkülönböztette a programozást és a szoftverfejlesztést azáltal, hogy a szoftverfejlesztést úgy definiálta, mint „a többszemélyes programok többszemélyes fejlesztése” (nem emlékszik, hogy ezt mondta volna) , de David Parnas ragaszkodik ehhez). Arra a következtetésre jutott, hogy a mezõ megnövekedett, mint éretté vált, megkérdőjelezve, vajon túl messzire mentünk-e mérnöki tudományágnak nevezni, és megkíséreljük a közösséget egy másik nyelv és egy újabb technika feltalálására.

Brian beszélgetését az 1968-as konferencia eredeti résztvevőinek négy tagja követte. Az egyik megvitatott kérdés az volt, hogy mit bántak az elmúlt ötven évben. Felhívták a figyelmet arra, hogy nem koncentrálnak a követelmények kidolgozására, a félreértésekre és a szoftverkarbantartásra. A 60-as években csalódottak voltak, és most csalódottak. Néhány panelező izgatott volt a formális módszerekkel kapcsolatban, de csalódtak az elfogadás hiánya miatt. Csalódtak voltak arról is, hogy mennyire kevés felfedeztünk arról, hogyan vezérelhetjük a szoftver tulajdonságaival kapcsolatos tervezési döntéseket. Összességében azonban úgy tűnt, hogy kevés egyetértés van abban, hogy a dolgok javultak-e vagy sem. Bizonyára összetettebb dolgokat építünk, de jobbak-e időben?

Hal, fedőszalag és diavetítések

A csütörtök esti bankett egy hajógyárban zajlott, és a tevékenységek furcsa pasztíza volt. Bankett-stílusú étkezés volt, Ph.D.-vel egy szabadtéri színpad. hallgatók rock zenét énekeltek, és egy svéd borító együttes vacsorában énekelt a 90-es és 2000-es pop dalokat, miközben a háziasszony ünnepelte a szoftverfejlesztő közösséget, és meghívta a konferencia szervezőit a színpadra, hogy köszönetet mondjanak. Vacsora közben diavetítés játszott mindenféle tetszőleges szoftver termék logóval a számítás történetéből, alkalmanként visszamenőleges videóval a szoftverfejlesztő világítótestek interjúival. Szokatlan volt, elválaszthatatlan és zavaró, különösen, ha egy csomó résztvevő kivágta a rendezvény helyének sarkát, hogy táncoljon.

Szoftvertervezés tánc party!Robert McClure, az 1968. évi NATO-konferencia egyik résztvevője.

Péntek reggel találtam a csütörtök visszamenőleges elemzőinek egyik tagját, Robert McClure-t, aki egyedül ült a szünet alatt, és úgy döntöttem, hogy beszélgetést kezdek. Az 1968-as konferencia eredeti résztvevője volt, és az iparág aktív gondolkodásvezetője, a haladást támogatva. Megkérdeztem tőle, mi változott 50 év alatt, mi nem, és mi az ő elképzelése a fejlődésről. Izgalmas, széles körű beszélgetés volt a szoftverfejlesztés számos alapvető kérdéséről. Kezdetben megvitatta néhány kritikai különbséget a szoftver tervezése (ami egy probléma és annak kontextusának megértését igényli), a mérnöki tervezés (amely megköveteli a megoldás alapos meghatározását) és a mérnöki munka (amely a specifikáció pusztán megvalósítása) között. Robert összehasonlította a szoftverfejlesztést és a többi mérnöki tudományágot, ezért megkérdeztem tőle, hogy mit gondol az alapvető különbségek, ha vannak. Azt javasolta, hogy ez fok kérdése. Arra gondoltam, hogy a kritikus különbség abban rejlik, hogy a tervező vagy a mérnöki tervező magabiztos lehet-e a probléma vagy a specifikáció megértésében; A hidat építő webhely megértése a természettudományokra támaszkodik, amelyek olyan mértékben kiszámíthatóak, hogy nem igazak az emberi, társadalmi és szervezeti rendszerekre, amelyekre általában a szoftvert tervezték. Ez a bizalomhiány szükségessé teszi a prototípuskészítést, a visszacsatolást és az evolúciót, amely nem szükséges más mérnöki tudományágakhoz (és nem is megvalósítható). Beszéltünk mindezen készségekhez szükséges oktatásról és a várt változás mértékéről is. Az elmúlt 50 évben sokkal több változást várt, mint amennyit észrevettek, és feltételezte, hogy az emberi természet sokkal ellenállóbb a változásokhoz, mint amennyire valaha is hitt. Azt javasoltam, hogy ez csak a hatékony oktatás kudarca lehet, összekapcsolva a fejlesztők számának gyors növekedését az 1968-as kb. 10 000-ről 2018-ban 30 millióra. Ő ösztönözte, hogy enyhítsék a változással kapcsolatos várakozásaimat; Mondtam neki, hogy hivatalban levő professzorként a következő 40 évben vagyok, és türelmes vagyok.

Brian Randell, szoftverfejlesztési történész.

Véletlenszerűen találtam Brian Randell-t is, a csütörtök 50 éves szoftverfejlesztési vitaindítóját, aki egyedül ült. Megkérdeztem tőle, miért gondolja, hogy a 2. NATO-konferencia annyira kiábrándító, és milyen hatása volt a véleménye szerint a szoftvermérnöki kutatások és gyakorlatok következő évtizedeiben. Azt állította, hogy a probléma nagy része az volt, hogy a 2. évben két részre osztottak szétválasztást. Először néhányan elképzeltek egy olyan világot, amelybe teljesen hiányos szoftvereket tudunk szállítani, mások szerint ez nem lehetséges, ezért meg kellene terveznünk. A második dimenzió mellett egyesek érdeklődtek a szoftverfejlesztés problémájának dekonstruálása iránt, mások pedig az eszközök, technikák és egyéb megoldások iránt érdeklődtek, amelyek véleménye szerint javíthatják azt. A résztvevők, akik ezen a vonalon oszlanak meg, csak nem tudták megbirkózni. Az idealisták és a realisták nem tudták, hogyan kell együttműködni, és a problémaközpontú túl sok időt töltött a megoldásközpontú emberek megoldásainak kritikáján, míg a megoldásközpontú emberek ellenálltak a visszajelzéseknek. Azt javasoltam, hogy ezeknek a megoszlásoknak sok a mai napig létezik a modern szoftverfejlesztési kutatásban, és megköszöntem Briannek, hogy segített megvilágítani e megosztottság történelmi eredetét.

Ivar egy történetet nyitott megszólaltatva.

Ivar Jacobson, az UML és a Rational Unified Process egyik fő támogatója beszédet tartott: „50 éves szoftverfejlesztés, szóval most mi lesz?” Anekdotával kezdte az egyik első szoftverfejlesztési projektjét, ahol be kellett vallania , semmit sem tudott a szoftverfejlesztésről. És mégis vezette a történelem egyik legsikeresebb svéd termékét. A szoftver sikerének értelmezése végső soron az üzleti modellek és fejlesztők, nem pedig a szoftver, és nem a folyamat eredménye. Véleménye szerint 50 év elteltével ez mégis inkább kézműves, mint mérnöki tudományág. Valójában a történelemben azt állítja, hogy sokkal inkább a divat hajtja végre, mint a tudományt: objektum-orientáció, UML, CMMI, Agile és bármi, ami következő, minden divat volt és lesz. Ivar érvelése az volt, hogy a háborúk mindegyike zavaró tényező volt. Ivar szerint az igazi probléma az, hogy a módszerek valóban gyakorlati összetételek, és a módszerek monolitikusak és a guruk által őrzött börtönökben csapdába esnek. Ivar véleménye szerint ez éretlen és ostoba.

Ajánlása az volt, hogy összpontosítson a módszerek közös gyakorlatának megtalálására, a módszerek modulálására és a módszerek szabad gyakorlataira. Beszélt egy szabványügyi testületről, amely elképzelést fogalmazott meg azokról a gyakorlatokról, amelyeknek tevékenységei vannak, amelyeknek vannak bizonyos sikerkritériumai, és olyan munkatermékekről, amelyek olyan tevékenységekből származnak, amelyeket e sikerkritériumok alapján értékelnek. Kulcsfontosságú pontja azonban az, hogy mindez megköveteli a fejlesztőktől, hogy kompetenciákkal rendelkezzenek ezekben a dolgokban. A siker kritériumai az ügyfelek igényeinek, a kidolgozott megoldásnak és a megvalósításukhoz szükséges csapatnak köszönhetők. Több további részletet mutatott be azokról az államokról, amelyekben a modellje átmegy. Amit nekem leírt, úgy hangzik, mint a folyamat tudományos elmélete és ebből az elméletből származó folyamatötletek halmaza; kipróbálni és finomítani kell valamit, nem pedig az evangéliumot. Végül valójában leíró elméletnek nevezte, és felszólította a kutatókat, hogy tovább fejlesszék azt prediktív és magyarázó elméletgé.

Közvetlenül Ivar beszéde után elmondtam az ICSE legbefolyásosabb papír díját. A díjbeszélgetés közepén meg tudtam mondani, hogy az emberek fáradtak és készen állnak a hét végére. A beszélgetésem komor, reflektív hangú, de biztató hangot adott, és bár a beszélgetés utáni csend fojtónak érezte magát, a Twitterben zajló beszélgetés élénkítette, megmutatva egy olyan közösséget, amely valóban hisz és értékeli azt, amit mondanom kellett, és éhes az útmutatásért. hogyan kell csinálni.

Andreas megkezdi díjbeszélését

Andreas Zeller azonnal beszélt, miután megkapta a SIGSOFT kutatási díját. Három történetet adott karrierjéről, mind a hatásra összpontosítva. Az első történet az első projektjéről és bemutatójáról szólott, amelyben megoldást adott egy problémára. Csalódva a visszajelzésről, visszapattant, amikor a GNU DDD hibakeresőre összpontosított, amelynek valódi gyakorlati hatása volt. Első epipániája az volt, hogy a valódi problémák megtalálása annyira nélkülözhetetlen, ugyanakkor egy nagyszerű módja annak, hogy befolyásolja. Második története az egyszerűségről szól. Valaki egy konferencián valaki felháborodott, hogy a deltahiba-ötlete annyira egyszerű. Ez impostor szindrómához, az értelmi alsóbbrendűség érzéséhez vezetett. De idővel rájött, hogy az egyszerűség hatalom; a bonyolultság kudarc volt. Végső története arról a munkáról szól, amelyet Tom Zimmermann-nal kezdte a bányászati ​​szoftverek tárolására. Megfigyelte, hogy a korai munkájuk eredményeivel kapcsolatos félelmek egyszerűen nem számítanak, mert az a tény, hogy a munka új. Az innováció a világ sötét, alul tanulmányozott, de releváns részeinek tanulmányozásáról szól. Végül Andreas azt állította, hogy az egyetlen dolog, amely tényleg számít, az a hatás. Inspiráló felhívással érkezett álmaink folytatására és kitartásra.

Búcsút mondva Göteborgnak, kihívást jelent az, hogy összefoglalom mindazt, amit megtanultam az idei ICSE-n. De mindenképpen próbáljuk meg:

  • Végül mindannyian ebben a közösségben vagyunk a szoftver fejlesztése érdekében. Koncentráljunk erre, nem pedig a rövid távú mutatókra.
  • Nagyobb ötletekre van szükség, valószínűleg elméletek formájában, hogy irányítsanak minket és irányítsák a hatásainkat.
  • A fenti célok elérése érdekében relevánsnak, nem pedig a közzétételnek kell gondolkodnunk.
  • Nem vesszük figyelembe a szoftverfejlesztés emberi tényezőit.

Ezek olyan leckék, amelyeket közösségünk minden tagjának végre kell hajtania. 50 év telt el, amikor felismertük azok fontosságát, és csak most kezdjük el komolyan venni őket.