Raport z podróży ICSE 2018: 50 lat inżynierii oprogramowania

Większość przewodniczących ogólnych i przewodniczących programowych wszystkich 40 spotkań ICSE.

W tym roku dziedzina badań inżynierii oprogramowania ma 50 lat; największa, najstarsza i najlepsza konferencja inżynierii oprogramowania, Międzynarodowa Konferencja Inżynierii Oprogramowania, ma 40 lat. Tegoroczna konferencja była doskonałą okazją dla społeczności, aby spojrzeć wstecz na ostatnie pół wieku badań i zapytać: „Czego się nauczyliśmy? O czym zapomnieliśmy Czego nam brakuje? ”Spędziłem tydzień w Göteborgu w Szwecji, zastanawiając się nad tym pytaniem, zastanawiając się nad licznymi wnikliwymi uwagami i przemówieniami, które odpowiadały na te pytania, ale także dzieląc się własnymi przemyśleniami na temat tego, jak przejść dalej przez dwie zaproszone rozmowy.

Aby rozpocząć mój pierwszy pełny dzień, wygłosiłem przemówienie otwierające w repozytoriach oprogramowania wydobywczego.

Zacząłem swój czas na ICSE, dając wspólne przemówienie na ICPC 2018 i MSR 2018 na temat pilnej potrzeby interdyscyplinarnej pracy i teorii w badaniach inżynierii oprogramowania, wykorzystując społeczności skupiające się na zrozumieniu i eksploracji jako przykładach tych większych punktów. O moim wystąpieniu pisałem w poprzednim poście, podsumowując moje argumenty. Po mojej rozmowie i podczas konferencji zaangażowałem się w naprawdę interesujące rozmowy z obojgiem starszych badaczy, którzy starali się zrozumieć, co rozumiem przez teorię, ale także z nowym doktoratem. studenci zafascynowani potencjałem teorii, aby uczynić swoją pracę bardziej wpływową. Odbyłem świetną rozmowę grupową z kilkoma doktorantami CMU na temat tego, czym jest teoria, jak ona wygląda, jak może zmienić nasze badania i jak może pogłębić nasze wyniki. Rozmawiałem również z inżynierem z Adobe Analytics, który walczył o pozyskanie wewnętrznych użytkowników narzędzi analitycznych. Była to fascynująca okazja, aby spróbować wpłynąć na sposób, w jaki kolejne pokolenie badaczy i inżynierów włączyło teorię do pracy, ale zastanawiałem się, jak skutecznie uczyć teorii używania.

W poniedziałek spędziłem trochę czasu na sesjach MSR i ICPC, słysząc o najnowszych odkryciach dotyczących postrzegania komunikatów o błędach, interpretacji wzorców projektowych i innych wysiłkach w celu zbadania zrozumiałości. W jednej pracy powtórzono ocenę 121 związanych z kodem wskaźników złożoności, aby sprawdzić, czy korelują one z własnym doświadczeniem programisty w zakresie zrozumiałości, stwierdzając, że długość i nazwy zmiennych wspólnie przewidują oceny deweloperów. Istnieją naprawdę sprytne wykorzystanie danych na tych mniejszych konferencjach w tej samej lokalizacji, zadając naprawdę interesujące pytania na styku rozumienia i wyszukiwania. Jak zauważyłem w moim przemówieniu, naprawdę potrzebują teorii na temat zrozumienia, ale wzorce, które znajdują, są dobrą podstawą do opracowania tych teorii.

W poniedziałek po południu odbyłem porywającą rozmowę z Timem Menziesiem na temat względnych zalet modeli głębokich i płytkich. Odpowiedział na moją przemowę częściowo ze zdziwieniem, że nie zgłosiłem głębszej krytyki społeczności zajmującej się wydobywaniem repozytoriów, ale także, że nie uznałem zdumiewającej mocy prostych, płytkich modeli do optymalizacji i skalowania wszelkiego rodzaju decyzji w oprogramowaniu Inżynieria. Jego argument był zasadniczo taki, że w niektórych przypadkach, a może nawet wielu, nie musimy wyjaśniać, dlaczego narzędzia, systemy lub procesy działają, one po prostu muszą działać. Rozpracowaliśmy nieporozumienia, ostatecznie dochodząc do wniosku, że prawdopodobnie potrzebujemy modeli różnego rodzaju głębokości (od teorii po niewyjaśnione prawa do bezmyślnych, ale dokładnych silników predykcyjnych). Taka różnorodność jest prawdopodobnie znakiem zdrowego dyskursu akademickiego.

Bankiet MSR w Muzeum Kultury Światowej w Göteborgu.

W poniedziałek wieczorem odbył się bankiet na konferencji Repozytoria oprogramowania wydobywczego. Przeprowadziłem bogaty zestaw rozmów z Mei Nagappanem, Andym Zaidmanem i Michaelem Godfreyem. Rozmawialiśmy o wszystkim, od kadencji i promocji, uczenia się na dużą skalę CS, naszych osobistych historii wokół uczenia się do programowania, a także o naszych rolach strażników w nauczaniu CS. Dla mnie takie rozmowy to głęboka istota sieci akademickich: są to rozmowy na temat naszego życia, naszych pomysłów i sposobu ich interakcji.

Abram mówi o potrzebie stopniowego postępu naukowego.

We wtorek rano Abram Hindle wygłosił najbardziej wpływową referat na temat swojej gazety: „Co mówią nam duże zobowiązania? Studium taksonomiczne dużych zobowiązań? ”. Co było znaczące w tym artykule, to fakt, że był to jeden z pierwszych artykułów, który nie tylko rozwinął techniki wydobywcze, ale faktycznie zadał pytanie o zawartość repozytoriów, przesuwając pole w kierunku bardziej naukowych pytań o oprogramowanie inżynieria, a nie tylko techniki wydobywcze. To, co uznałem za naprawdę interesujące w tej pracy, to to, w jaki sposób jej opinia była naukowo uzasadniona: mocno twierdziło, że wartości odstające są ważne i nie można ich pominąć, a duże wartości odstające są naprawdę krytycznymi wskaźnikami dotyczącymi natury ewolucji oprogramowania. Skoncentrował się także wyjątkowo na szczegółowej analizie zmian commits, która była (i nadal jest) rzadką metodą we wszelkich badaniach eksploracji danych. Abram przytoczył również przekonujący argument, że odrzucenie prac z powodu braku natychmiastowych wyników podważa naszą naukę, a tym samym naszą przyszłość, i jest sprzeczne z tym, o co chodzi ze stypendium. W pytaniach i odpowiedziach Abram przedstawił kilka wnikliwych uwag na temat ekonomiki badań i tego, w jaki sposób może wypaczać pytania, które stawiamy, oraz na temat głębokości badań naukowych, na które zezwalamy.

Podczas przerwy Lutz Prechelt zadał mi fascynujące pytanie: dlaczego pomimo tego, że oprogramowanie jest tak złożone, a programiści są tak nieprzygotowani, że mimo to oprogramowanie jest budowane, adoptowane i wykorzystywane w sposób produktywny? Zastanowiłem się przez chwilę i podzieliłem moją wielką teorią. Wyjaśniłem, że oprogramowanie, mimo że ma faktycznie nieskończoną przestrzeń stanów wykonań i jest nieskończenie niezrozumiałe dla programistów, w rzeczywistości ma tylko niewielką odpowiednią przestrzeń stanów używanych w praktyce przez użytkowników. Oznacza to, że pomimo całej tej złożoności, programiści są w stanie zdobyć wystarczającą wiedzę na temat tej istotnej przestrzeni wykonywania i zapewnić, że oprogramowanie jest dla nich skuteczne i niezawodne. Nawet wtedy, gdy oprogramowanie nie jest skuteczne i niezawodne, podejrzewam, że użytkownicy są odporni na większość napotkanych niepowodzeń, znajdując obejścia lub zmieniając swoje cele w oparciu o zachowanie. Ta teoria odporności wyjaśnia, dlaczego oprogramowanie jest cenne, mimo że jest kruche. Nie oznacza to, że awarie oprogramowania nie mają znaczenia: występują poważne awarie, które często wynikają z braku dokładnego zrozumienia przez deweloperów, które części przestrzeni stanów złożonego systemu oprogramowania mają tak naprawdę znaczenie w terenie. Ponadto programiści często nie dysponują narzędziami ani danymi niezbędnymi do uzyskania tej dokładnej wiedzy. Ponadto istnieje wiele podskładników systemów, które są całkowicie zautomatyzowane i musimy je formalnie zweryfikować, aby zapobiec poważnym awariom na dalszych etapach. Istnieją również istotne kwestie związane z ludźmi w pętli, które wymagają dodatkowej szczególnej uwagi, aby uzyskać właściwe, wymagające metod HCI. Tak więc, jak świat jest odporny na kruche oprogramowanie, możemy i musimy robić lepiej.

Zrobiłem przerwę we wtorek na lunch, aby porozmawiać z młodszym kolegą na temat doradzania doktorantom. Zadawał doskonałe pytania, które stanowiły dla mnie świetną podstawę do refleksji na temat moich praktyk. Dużo mówiłem o definiowaniu kultury i mojej nowej strategii pisania dokumentu pokładowego, który określa oczekiwania. Mówiłem o bezpieczeństwie psychicznym jako fundamencie budowania zaufania w relacjach z moimi uczniami i zespołem. Mówiłem o krytycznej potrzebie faktycznego egzekwowania i modelowania norm w moim dokumencie dotyczącym wdrażania w celu wzmocnienia kultury mojego laboratorium. Dzieliłem się pomysłami na temat łączenia studentów w celu zwiększenia odpowiedzialności, różnorodności pomysłów i częstotliwości przekazywania opinii. Omówiłem również napięcia przed kadencją, które mogą wynikać z potrzeby publikacji, ale także z konieczności zapewnienia uczniom miejsca na naukę, a także jak rozwiązać te napięcia, utrzymując osobny wątek pierwszych opracowań. Co najważniejsze, przypomniałem temu koledze, że nauka się nie kończy. Znam starszych kolegów, którzy wciąż szukają porady po dziesięcioleciach nauki.

Zjadłem cudowną kolację we wtorek wieczorem z Thomasem LaTozą i doktorem. student August Shi, w którym przeprowadziliśmy szeroko zakrojoną dyskusję na temat podstawowych i stosowanych badań inżynierii oprogramowania, roli nauk społecznych w badaniach inżynierii oprogramowania oraz potrzeby bardziej uczciwych, uzasadnionych teoretycznie relacji z leżących u podstaw założeń dotyczących pracy w tej dziedzinie.

Magnus Frodigh, prezes Ericsson Research, w środę wygłosił mowę otwierającą na temat komunikacji bezprzewodowej i 5G. Zaczął od przewidywania szybkiego tempa zmian w naszych doświadczeniach cyfrowych, ale także wolniejszego tempa zmian w infrastrukturze sieci. Argumentował, że stabilność standardu 5G byłaby wystarczająca dla wszystkich rodzajów nowej transformacyjnej infrastruktury IoT, w tym komunikacji między maszynami w czasie rzeczywistym. Zagłębił się głęboko w szczegóły infrastruktury 5G, które uważałem za suche i w większości nieistotne dla inżynierii oprogramowania, ale fascynująca wizja ukryta w rozmowie była niewyobrażalną skalą łączności między ludźmi i maszynami, która zasadniczo eliminuje opóźnienia. Magnus argumentował, że dzięki temu prototypowanie nowych doświadczeń będzie znacznie łatwiejsze, ponieważ systemy można skomponować w całości za pomocą usług sieciowych o niskim opóźnieniu, a nie poprzez wdrożenia sprzętowe.

W środową poranną przerwę Walter Tichy, James Herbsleb i ja rozmawialiśmy produktywnie o tym, jak zmienić wykorzystanie społeczności naukowców zajmujących się inżynierią oprogramowania i rozwój teorii. Zaczęliśmy od obserwacji, w jaki sposób pole ma teorie, są one po prostu dorozumiane, a jeśli zostaną wyraźnie określone, mogą spowodować, że ponownie przemyślimy nasze założenia i kierunki badań. Na przykład w polu znajdują się teorie mocy abstrakcji, pojęcia podatności na błędy w projektowaniu języka programowania oraz sposób działania programu. Po prostu nie ujawniamy tych teorii. James również przedstawił przemówienie na temat teorii, a on i ja otrzymaliśmy ciepłe odpowiedzi na nasze wezwania do większej teorii, więc podejrzewamy, że dziedzina jest gotowa do nauki. Zastanawialiśmy się nad sposobami edukacji społeczności, w tym nad opracowaniem niektórych lekkich materiałów do nauczania nowych doktorantów lub zainteresowanych wykładowców. Omówiliśmy potencjalną organizację Dagstuhl w celu opracowania i wdrożenia tych materiałów.

Chris Parnin omawia kompleksowość nauczania złożoności.

Resztę środy spędziłem na sesjach związanych z edukacją i szkoleniem w zakresie inżynierii oprogramowania (które będę współprzewodniczyć w 2020 r., Ale uważam również, że jest to bardzo ważne i kluczowe dla moich zainteresowań w edukacji komputerowej). Ten utwór publikuje rygorystyczne, recenzowane badania dotyczące edukacji komputerowej na temat inżynierii oprogramowania. Chris Parnin rozpoczął pierwszą sesję rozmową o wykorzystaniu iTrust, dużego złożonego wdrożenia oprogramowania, do nauczania inżynierii oprogramowania. Odkrył, że studenci docenili znacznie później po zakończeniu kursu głębokie zaangażowanie w duży złożony system, ale nie cieszyli się tym podczas całego kursu. Praca ze starszym kodem była przytłaczająca. Zrewidowali kurs, dostosowując zajęcia klasowe do samego projektu, co doprowadziło do o wiele bardziej pozytywnych opinii na temat kursu (jak można się spodziewać; uczniowie potrzebują spójnej narracji wokół zajęć klasowych, aby utrzymać swoje zaangażowanie). Kolejna rozmowa wykazała, że ​​aktywne oglądanie wideo, w którym uczniowie komentują treść i recenzują komentarze, zwiększa zaangażowanie w oglądanie filmów. Niektóre rozmowy koncentrowały się na laboratoriach, nagrobkach i innych eksperymentalnych projektach edukacyjnych. Zasadniczo badania te wykazały, że uczenie się przez doświadczenie jest naprawdę trudne do przeprowadzenia logistycznie, co stanowi wyzwanie dla autentyczności i bardzo trudno jest umieć ocenić. Wygląda na to, że potrzebujemy teorii uczenia się przez doświadczenie, aby zorganizować tę pracę.

Reid Holmes omawia rzeczy, które uczniowie lubili uczyć.

Reid Holmes przedstawił ładne studium podłużne kanadyjskiego programu nauki opartej na doświadczeniu dla wysoko wydajnych studentów informatyki (studia licencjackie Capstone Open Source Projects). W badaniu odkryto zaskakująco pozytywne doświadczenia z uczniami, którzy bardzo cenią zastosowanie swojej wiedzy w klasie do prawdziwych, nowatorskich zadań, do prawdziwych projektów ze społecznością użytkowników, jednocześnie otrzymując opiekę od prawdziwych programistów. Ciemnym podbrzuchem tej pracy jest sposób wybierania studentów: program wyraźnie wybiera najlepszych studentów z wielu instytucji, co pozwala uniknąć wielu wyzwań związanych z nauką, które mogą pojawić się w przypadku mniej przygotowanych studentów.

Las deszczowy Universeum był naprawdę wilgotny!

Środowe przyjęcie odbyło się w Universeum, muzeum przyrodniczym pełnym zwierząt, ryb i ogromnego wilgotnego lasu deszczowego. To był naprawdę interesujący kontekst dla przyjęcia, ponieważ zamiast być dużą otwartą przestrzenią do rozmów, był pełen interaktywnych eksponatów, które angażowały uczestników wokół zabawy i eksploracji. Eksponaty nie były szczególnie zachęcające ani przekonujące, ale były na tyle dobre, że zapoczątkowały wszelkiego rodzaju ciekawe rozmowy, których w innym przypadku prawdopodobnie byśmy nie odbyli. Rozmawiałem z uczestnikami o potworach Gila, grzechotnikach, meduzach, utrzymywaniu oprogramowania wystaw opartych na oprogramowaniu oraz o szerokiej gamie cynizmu, który przeniknął do akademickiej informatyki.

W czwartek rano zjadłem śniadanie z Brendanem Murphym, Laurie Williams i dr UW. student Calvin Loncaric w naszej hotelowej sali śniadaniowej. Przeprowadziliśmy szeroko zakrojoną dyskusję na temat dwóch wielkich wyzwań, które są mi bliskie: pogodzenie systemów formalnych, takich jak języki programowania z systemami ludzkimi i społecznymi, oraz pogodzenie systemów statystycznych, takich jak uczenie maszynowe z systemami ludzkimi i społecznymi. Moim zdaniem są to dwa najważniejsze wielkie wyzwania w informatyce, a jednak większość ludzi w informatyce je ignoruje. Brendan miał wiele do powiedzenia na temat złożoności ujednolicenia analizy danych i uczenia maszynowego z prawdziwymi projektami, Laurie dużo mówił o tych samych wyzwaniach związanych z bezpieczeństwem w tworzeniu oprogramowania, a Calvin rozważał te problemy we własnej pracy nad syntezą struktury danych, gdzie rozważania dotyczące zrozumiałości zsyntetyzowanego kodu i możliwości poznania jego języka specyfikacji są pytaniami otwartymi.

Fred Brooks Jr., interpretując historię.

Były dwa wykłady czwartkowe rano. Fred Brooks, Jr., autor seminarium The Mythical Man-Month na temat zarządzania projektami oprogramowania, przedstawia retrospektywę. Fred mówił o ewolucji programów, oprogramowania, systemów oprogramowania, produktów programowych. Następnie zdefiniował inżynierię oprogramowania jako dyscyplinę wytwarzania oprogramowania. Mówił o wielkich pomysłach w historii inżynierii oprogramowania, w tym programach von Neumanna jako danych i językach programowania wysokiego poziomu, takich jak COBOL i FORTRAN. W latach 60. kryzys oprogramowania (wyzwanie związane z budowaniem dużych systemów) doprowadził do pomysłu inżynierii oprogramowania jako inżynierii. Wielkim uznaniem było to, że wzrost złożoności projektu nie był liniowy. Wiele z tego przyczyniło się do wkładu systemów, takich jak interaktywne debugowanie Toma Kilburna i system operacyjny dzielenia czasu Fernando Corbato, systemy baz danych, pomysły formalnej weryfikacji Roberta Floyda i Tony'ego Hoare'a oraz orientacja obiektowa Simuli. W latach 70. pojawiło się ukrywanie informacji Davida Parnasa, abstrakcyjne typy danych Barbary Liskov, stopniowe udoskonalanie Harlana Millsa i Niklausa Wirtha, inspekcje kodu Michaela Fagana i zarządzanie projektami oprogramowania. Barry Boehm zadał również pytania dotyczące wymagań i sprawdzania poprawności wymagań. Bardzo polecił seminarium internetowe ACM Grady Boocha na temat historii inżynierii oprogramowania i wkładu Barry'ego Boehma w całe życie.

Margaret Hamilton dzieli się historiami programowania komputerów mainframe.

Drugim głównym mówcą w czwartek rano była Margaret Hamilton, która przewidziała wyrażenie „inżynieria oprogramowania”. Była studentką matematyki, kiedy postanowiła odbyć staż w MIT, opracowując oprogramowanie pogodowe na LGP30, i zainteresowała się oprogramowaniem, a ostatecznie zbudowała Apollo systemy oprogramowania, które pozwoliły Stanom Zjednoczonym wylądować na Księżycu. W swoim przemówieniu „The Language as a Software Engineer” mówiła o wielkich problemach: integracja, rozwój jest trudny, ponowne użycie jest trudne, a oprogramowanie zawiedzie. Zapytała, dlaczego zrobiliśmy tak mało postępów w ciągu 50 lat? Twierdziła, że ​​było ich trochę. Wcześniej nie było pola; teraz jest. Zdefiniowaliśmy terminy. Ale w rzeczywistości inżynieria oprogramowania jest pracą wyraźnie ludzką, społeczną i intelektualną, a my wciąż nie mamy do czynienia z większością tych czynników. Podała przykłady podstawowych wyzwań HCI związanych z tworzeniem interaktywnych systemów między ludźmi, oprogramowaniem, błędami i odzyskiwaniem błędów, a także tego, w jaki sposób były one kluczowe dla lądowania na Księżycu. Zdała sobie sprawę, że systemy są z natury asynchroniczne, rozproszone i sterowane zdarzeniami, a języki używane do pisania oprogramowania powinny to odzwierciedlać. Zbilansowała to, omawiając potrzebę planowania poprzez architekturę za pomocą niezawodnych wzorów wielokrotnego użytku. Byłem dumny, widząc w Q&A rozpoznanie przez społeczność historii, jej wartości i odległych początków niektórych z największych pomysłów w tej dziedzinie.

Miryung Kim z UCLA mówi o fascynującym badaniu ról związanych z nauką danych.

W czwartek przewodniczyłem sesji zatytułowanej „Studiowanie inżynierów oprogramowania”, która obejmowała cztery fascynujące badania empiryczne, w tym dwie publikacje TSE po raz pierwszy. Pierwszy, „Zrozumienie potrzeb deweloperów dotyczących wycofania jako funkcji językowej” (autor: Anand Sawant z TU Delft) odkrył wiele przydatnych trendów dotyczących używania i niewłaściwego używania funkcji wycofania, identyfikując potrzeby dotyczące dat wycofania, ostrzeżeń o dotkliwości i większej różnorodności typów ostrzeżeń. Drugi artykuł „O dychotomii zachowań debugujących wśród programistów” (autor: Moritz Beller z TU Delft) odkrył, że w praktyce narzędzia do debugowania są rzadko używane, że „debugowanie printf” pozostaje dominujące, a znajomość narzędzi do debugowania jest dość duża Niska. Pierwszy artykuł w czasopiśmie „Pomiar zrozumienia programu: badanie terenowe na dużą skalę z udziałem profesjonalistów” (Xin Xia, Lingfeng Bao, David Lo, Zhenchang Xing i Shanping Li) wykazał, że programiści spędzają większość czasu na zrozumieniu kod, że używają przeglądarek internetowych i edytorów do zrozumienia kodu oraz że im więcej doświadczenia ma programista, tym mniej czasu poświęcają na zrozumienie. Ostatni artykuł w sesji „Data Scientists in Software Teams: State of the Art and Challenges” (Miryung Kim, Thomas Zimmermann, Robert DeLine i Andrew Begel) przeprowadził ankietę wśród 793 profesjonalnych naukowców zajmujących się danymi i okazał się naprawdę interesujący zestaw 9 rodzajów ról związanych z nauką danych: polimaty, ewangeliści danych, osoby przygotowujące dane, osoby kształtujące dane, konstruktorzy platform, księżycowcy różnych stopni i aktorzy wglądu, którzy interpretowali dane i używali ich do podejmowania decyzji. Ta bogata dekonstrukcja lub różne role wydają się naprawdę potężne dla informowania o edukacji informatycznej.

Ostatnia sesja w czwartek była świętem 50-lecia inżynierii oprogramowania. Brian Randell przedstawił retrospektywę na temat pierwszej inżynierii oprogramowania w 1968 roku. Brian mówił o tym, jak niewiele jeszcze wynaleziono w branży komputerowej; bez internetu, bez sieci, bez ponownego użycia. A jednak były tam wszystkie problemy: testowanie, poprawność, zarządzanie itp. Brian rozróżniał programowanie i inżynierię oprogramowania, definiując inżynierię oprogramowania jako „wieloosobowy rozwój programów wieloosobowych” (nie pamięta, by to powiedzieć) , ale David Parnas nalega, aby to zrobił). Doszedł do wniosku, że dziedzina ta urosła bardziej niż dojrzała, pytając, czy udało nam się nazwać ją dyscypliną inżynieryjną, i karcąc społeczność za wymyślenie jeszcze jednego języka i jeszcze jednej techniki.

Po przemówieniu Briana panel czterech pierwotnych uczestników konferencji w 1968 r. Jednym z omawianych przez nich pytań było to, czego żałują w ciągu ostatnich pięćdziesięciu lat. Podnieśli brak koncentracji na inżynierii wymagań, brak uwagi na błędnych informacjach, brak uwagi na temat konserwacji oprogramowania. Byli rozczarowani w latach 60. i są rozczarowani teraz. Niektórzy z panelistów byli podekscytowani metodami formalnymi, ale rozczarowani brakiem adopcji. Byli również rozczarowani tym, jak mało odkryliśmy, jak kierować decyzjami projektowymi w odniesieniu do jakości oprogramowania. Ogólnie jednak wydawało się, że nie ma zgody co do tego, czy sytuacja uległa poprawie, czy nie. Z pewnością budujemy bardziej złożone rzeczy, ale czy są one lepsze, bardziej na czas?

Ryba, opaska i pokazy slajdów

Czwarty wieczór odbył się w stoczni i był dziwnym pastiszem działań. Był posiłek w stylu bankietowym, scena plenerowa z doktoratem. studenci śpiewający muzykę rockową oraz szwedzki zespół coverowy śpiewający popowe piosenki z lat 90. i 2000 podczas kolacji, podczas gdy gospodyni świętowała społeczność inżynierii oprogramowania i zaprosiła różnych organizatorów konferencji na scenę, aby podziękować. Podczas kolacji pokaz slajdów z wszelkiego rodzaju logo dowolnego oprogramowania z historii komputerów, a także okazjonalne wideo z wywiadami z inżynierami oprogramowania. Było dziwne, rozczochrane i dezorientujące, zwłaszcza gdy grupa uczestników wykroiła róg miejsca imprezy, by tańczyć.

Impreza taneczna z inżynierią oprogramowania!Robert McClure, jeden z uczestników konferencji NATO w 1968 r.

W piątek rano znalazłem jednego z panelistów z czwartkowej retrospektywy, Roberta McClure'a, siedzącego samotnie podczas przerwy, więc postanowiłem rozpocząć rozmowę. Był jednym z pierwszych uczestników konferencji w 1968 r. I aktywnym liderem myśli w branży, opowiadającym się za postępem. Zapytałem go o to, co się zmieniło przez 50 lat, a co nie, i jaka jest jego koncepcja postępu. Odbyliśmy fascynującą, szeroko zakrojoną rozmowę na temat wielu podstawowych zagadnień w inżynierii oprogramowania. Zaczął od omówienia niektórych krytycznych różnic między projektowaniem tego, co robi oprogramowanie (co wymaga zrozumienia problemu i jego kontekstu), projektowaniem inżynieryjnym (które wymaga dokładnego określenia rozwiązania), a inżynierią (która jest czystą implementacją tej specyfikacji). Robert dokonał porównań między inżynierią oprogramowania i innymi dyscyplinami inżynierii, więc zapytałem go, jakie według niego są podstawowe różnice, jeśli w ogóle. Zasugerował, że to kwestia stopnia. Spekulowałem, że zasadniczą różnicą był stopień, w jakim projektant lub projektant inżynierski może być pewny, że rozumieją problem lub specyfikację; zrozumienie witryny, na której budujesz most, opiera się na naukach przyrodniczych, które są przewidywalne w stopniu, który nie jest zgodny z systemami ludzkimi, społecznymi i organizacyjnymi, dla których oprogramowanie jest zazwyczaj zaprojektowane. Ten brak zaufania stwarza potrzebę tworzenia prototypów, informacji zwrotnych i ewolucji, które nie są tak konieczne dla innych dyscyplin inżynieryjnych (a także nie są tak wykonalne). Rozmawialiśmy również o edukacji niezbędnej do zdobycia wszystkich tych umiejętności oraz oczekiwanym tempie zmian. Spodziewał się o wiele więcej zmian w ciągu ostatnich 50 lat, niż zauważył, i spekulował, że natura ludzka jest o wiele bardziej odporna na zmiany, niż kiedykolwiek sądził. Zasugerowałem, że może to być po prostu brak skutecznej edukacji w połączeniu z gwałtownym wzrostem liczby programistów z około 10 000 w 1968 r. Do 30 milionów w 2018 r. Zachęcał mnie do uspokojenia moich oczekiwań dotyczących zmian; Powiedziałem mu, że jako profesor zatrudniony przez następne 40 lat będę cierpliwy.

Brian Randell, historyk inżynierii oprogramowania.

Przez przypadek znalazłem również siedzącego samotnie Briana Randella, czwartego 50-letniego głównego mówcę inżynierii oprogramowania. Zapytałem go, dlaczego uważa, że ​​druga konferencja NATO była tak rozczarowująca, i jaki był jego wpływ na nadchodzące dekady badań i praktyki inżynierii oprogramowania. Argumentował, że znaczny problem polegał na tym, że w 2. roku były podziały wzdłuż dwóch. Po pierwsze, niektórzy wyobrażali sobie świat, w którym moglibyśmy dostarczać całkowicie wadliwe wolne oprogramowanie, a inni uważali, że coś takiego nie jest możliwe i powinniśmy to zaplanować. W drugim wymiarze niektóre osoby były zainteresowane dekonstrukcją problemu inżynierii oprogramowania, a inne były zainteresowane narzędziami, technikami i innymi rozwiązaniami, które ich zdaniem mogłyby go poprawić. Uczestnicy podzieleni według tych zasad po prostu nie mogli się dogadać. Idealiści i realistycy nie wiedzieli, jak współpracować, a skoncentrowani na problemach spędzili zbyt dużo czasu na krytykowaniu rozwiązań osób skoncentrowanych na rozwiązaniach, podczas gdy ludzie skoncentrowani na rozwiązaniach byli odporni na opinie. Zasugerowałem, że wiele z tych dywizji wciąż istnieje w dzisiejszych badaniach inżynierii oprogramowania i podziękowałem Brianowi za pomoc w wyjaśnianiu historycznych początków tych podziałów.

Ivar otwiera swoją główną myśl historią.

Ivar Jacobson, główny współpracownik UML i Rational Unified Process, wygłosił przemówienie zatytułowane: „50 lat inżynierii oprogramowania, więc co teraz?”. Zaczął od anegdoty na temat swojego pierwszego projektu inżynierii oprogramowania, w którym musiał przyznać , nic nie wiedział o inżynierii oprogramowania. A jednak nadal prowadził jeden z najbardziej udanych szwedzkich produktów w historii. Jego interpretacja sukcesu oprogramowania jest ostatecznie wynikiem modeli biznesowych i programistów, a nie oprogramowania i procesu. Jego zdaniem po 50 latach jest to raczej rzemiosło niż dziedzina inżynierii. W rzeczywistości twierdzi on, że modą bardziej kierujemy się modą niż nauką: orientacja obiektowa, UML, CMMI, Agile i wszystko, co będzie dalej, było i będzie modą. Argument Ivara był taki, że wszystkie wojny wojenne były rozproszone. Prawdziwy problem, według Ivara, polega na tym, że metody są tak naprawdę kompozycjami praktyk, a metody są monolityczne i uwięzione w więzieniach strzeżonych przez guru. W opinii Ivara jest to niedojrzałe i głupie.

Jego zaleceniem było skupienie się na znalezieniu wspólnej płaszczyzny metod, modularyzacji metod i wolnych praktyk od metod. Mówił o organie normalizacyjnym, który przewidział pojęcie praktyk, które mają działania, które mają pewne kryteria sukcesu, oraz produkty pracy, które pochodzą z działań, które są oceniane pod kątem tych kryteriów sukcesu. Jego kluczową sprawą jest jednak to, że wszystko to wymaga od programistów posiadania kompetencji we wszystkich tych sprawach. Kryteria sukcesu sprowadzają się do potrzeb klienta, tworzonego rozwiązania i zespołu, który je osiąga. Przedstawił kilka dodatkowych szczegółów na temat stanów, przez które przechodzi jego model. To, co mi opisał, brzmi jak naukowa teoria procesu i zestaw pomysłów na proces wywodzących się z tej teorii; coś do przetestowania i udoskonalenia, a nie ewangelia. W końcu nazwał ją teorią opisową i wezwał badaczy do dalszego rozwijania jej w teorię przewidywania i wyjaśniania.

Natychmiast po przemówieniu Ivara wygłosiłem przemówienie ICSE Most Influential Paper Award. W trakcie sesji wręczania nagród mogłem powiedzieć, że ludzie są zmęczeni i gotowi na koniec tygodnia. Moja rozmowa miała ponury, refleksyjny ton, ale zachęcający ton i chociaż cisza po niej była ogłuszająca, rozmowy na Twitterze były ożywcze, pokazując społeczność, która naprawdę wierzy i ceni to, co miałam do powiedzenia, i jest głodna wskazówek jak to zrobić.

Andreas rozpoczyna rozmowę o nagrodzie

Andreas Zeller przemówił zaraz za mną po otrzymaniu nagrody SIGSOFT Research Award. Opowiedział trzy historie o swojej karierze, wszystkie skupione na wpływie. Pierwsza historia dotyczyła jego pierwszego projektu i prezentacji, w których opracował rozwiązanie problemu. Rozczarowany informacją zwrotną, powrócił do pracy, skupiając się na debugerze GNU DDD, który miał realny praktyczny wpływ. Jego pierwszym objawieniem było to, że znalezienie prawdziwych problemów było tak ważne, ale także świetny sposób na wywarcie wpływu. Jego druga historia dotyczyła prostoty. Ktoś na konferencji był oburzony, że jego pomysł debugowania delty był taki prosty. Doprowadziło to do syndromu oszusta, poczucia niższości intelektualnej. Ale z czasem zdał sobie sprawę, że prostota to potęga; złożoność była porażką. Jego ostatnia historia dotyczyła pracy, którą rozpoczął z Tomem Zimmermannem przy repozytoriach oprogramowania do wyszukiwania. Zauważył, że obawy o wyniki ich wczesnej pracy po prostu nie miały znaczenia, ponieważ był to fakt, że praca była nowa. Innowacja polega na badaniu ciemnych, niedozwolonych, ale istotnych części świata. Ostatecznie Andreas argumentował, że jedyne, co naprawdę się liczy, to wpływ. Zakończył inspirującym wezwaniem do realizacji naszych marzeń i do wytrwania.

Pożegnanie z Göteborgiem jest trudne do podsumowania wszystkiego, czego nauczyłem się podczas tegorocznego ICSE. Ale spróbujmy mimo to:

  • Ostatecznie wszyscy jesteśmy w tej społeczności, aby ulepszać oprogramowanie. Skupmy się na tym, a nie na wskaźnikach krótkoterminowych.
  • Potrzebujemy większych pomysłów, najprawdopodobniej w formie teorii, które poprowadzą nas i pokierują naszym wpływem.
  • Musimy myśleć o trafności, a nie o możliwości publikacji, aby osiągnąć powyższe cele.
  • Na własne ryzyko ignorujemy czynniki ludzkie w inżynierii oprogramowania.

Są to lekcje, które każdy członek naszej społeczności musi ostatecznie przyswoić. Minęło 50 lat, odkąd uświadomiliśmy sobie ich znaczenie i dopiero zaczynamy traktować je poważnie.