Najtrudniejszym aspektem tworzenia oprogramowania jest nie kodowanie, a wymagania.
Wśród licznych artykułów o niesamowitym postępie w dziedzinie sztucznej inteligencji (AI) pojawia się wiele obaw dotyczących możliwości, że my, jako programiści, możemy wkrótce zostać bez pracy, zastąpieni przez AI. Wyobrażają sobie, że wszyscy prezesi firm i badacze produktowi obejdą większość lub wszystkich swoich programistów i poproszą AI o zbudowanie dokładnie tego, czego chcą lub potrzebują. Jako osoba, która spędziła 15 lat tworząc oprogramowanie na podstawie specyfikacji stworzonych przez tych ludzi, trudno mi poważnie traktować te obawy.
Kodowanie może stanowić wyzwanie, ale nigdy nie spędziłem więcej niż dwóch tygodni na próbie zrozumienia, co jest z nim nie tak. Po opanowaniu składni, logiki i technik jest to w większości przypadków dość prosty proces. Rzeczywiste problemy zwykle koncentrują się wokół tego, co oprogramowanie powinno robić. Najtrudniejszym aspektem tworzenia oprogramowania jest nie pisanie kodu – to tworzenie wymagań, a te wymagania oprogramowania nadal są definiowane przez ludzi.
Ten artykuł omówi związek między wymaganiami a oprogramowaniem, a także to, czego potrzebuje AI, aby uzyskać dobre wyniki.
To nie jest błąd, to funkcja.
Na początku mojej kariery w oprogramowaniu zostałem dodany do projektu w trakcie jego trwania, aby pomóc zwiększyć prędkość zespołu. Głównym celem oprogramowania było konfigurowanie produktów na stronach internetowych e-commerce.
Zostałem wyznaczony do generowania dynamicznych warunków umownych. Istniała wariantowość słownictwa zależna od typu produktu kupowanego, a także od stanu USA, w którym znajdował się klient ze względu na wymogi prawne.
W pewnym momencie myślałem, że znalazłem potencjalny defekt. Użytkownik wybierał jeden typ produktu, który generował odpowiednie warunki umowne, ale dalej w workflow pozwalało mu to wybrać inny typ produktu i zdefiniowane warunki umowne. Byłoby to naruszeniem jednej z funkcji wyraźnie uzgodnionych w wymaganiach biznesowych, które miały podpis klienta. Naiwnie zapytałem klienta: „Czy powinienem usunąć dane wejściowe, które umożliwiają użytkownikowi zastąpienie prawidłowych warunków umownych?” Odpowiedź, którą dostałem, została wyryta w mojej głowie od tamtej pory. Jego dokładne słowa zostały wypowiedziane z całkowitą i pełną pewnością siebie; „Nigdy się to nie zdarzy”.
Był to wiceprezes senior, który był w firmie od lat, znał procesy biznesowe firmy i został wybrany do nadzorowania oprogramowania z jakiegoś powodu. Możliwość zastąpienia domyślnych warunków umownych została wyraźnie zażądana przez tę samą osobę. Kto ja taki, by kwestionować kogoś, tym bardziej wiceprezesa seniora firmy, która płaciła nam za zbudowanie tego produktu? Zignorowałem to i szybko o tym zapomniałem. Miesiące później, tuż przed rozpoczęciem prac nad oprogramowaniem, tester po stronie klienta znalazł defekt, który został mi przydzielony. Kiedy zobaczyłem szczegóły usterki, wybuchłem śmiechem. To moje obawy dotyczące zastępowania domyślnych warunków umownych, rzecz, o której powiedziano mi, że nigdy się nie wydarzy? Zgadnij co się działo? Kto został za to obwiniony i kto został poproszony o naprawienie tego?
Poprawa była stosunkowo łatwa, a konsekwencje błędu były niewielkie, ale to doświadczenie było powtarzającym się motywem w mojej karierze budowania oprogramowania. Rozmawiałem z wystarczającą liczbą kolegów z branży oprogramowania, aby wiedzieć, że nie jestem sam. Problemy stały się większe, trudniejsze do naprawienia i droższe, ale źródło problemu jest zwykle takie samo: wymagania były niejasne, niespójne lub nieprawidłowe.
AI obecnie: szachy kontra samochody autonomiczne
Koncepcja sztucznej inteligencji istnieje już od dłuższego czasu, chociaż wysoki profil postępów wzbudził obawy w mediach oraz Kongresie. Sztuczna inteligencja odniosła już duży sukces w pewnych obszarach. Pierwszym, który przychodzi na myśl, są szachy.
AI została zastosowana w szachach już w latach 80-tych. Powszechnie uznaje się, że AI przewyższyła zdolność człowieka do wygrywania w szachach. Nie jest to zaskakujące, ponieważ parametry szachów są SKOŃCZONE (choć gra nie została jeszcze rozwiązana).
Szachy zawsze zaczynają się od 32 figur na 64 polach, mają dobrze udokumentowane, oficjalnie uzgodnione zasady i co najważniejsze, jasno określony cel. W każdej turze istnieje skończona liczba możliwych ruchów. Granie w szachy to po prostu przestrzeganie zasad. Systemy AI mogą obliczać konsekwencje każdego ruchu, aby wybrać ruch najbardziej prawdopodobny do zdobycia figury przeciwnika lub zyskania pozycji i ostatecznie wygrania.
Był jeszcze inny front, gdzie AI była bardzo aktywna – samochody autonomiczne. Producenci obiecują samochody autonomiczne już od pewnego czasu. Niektóre mają zdolność do samodzielnego prowadzenia, ale istnieją zastrzeżenia. W wielu sytuacjach samochód wymaga aktywnego nadzoru; kierowca może musieć trzymać ręce na kierownicy, funkcja autonomiczna nie jest niezależna.
Podobnie jak programy AI do gry w szachy, samochody autonomiczne w dużej mierze używają regułowych silników do podejmowania decyzji. W przeciwieństwie do programów szachowych, zasady, jak poruszać się w każdej możliwej sytuacji, nie są jasno określone. Kierowcy dokonują tysięcy małych osądów podczas jednej podróży, unikając pieszych, omijając podwójnie zaparkowane samochody i skręcając na ruchliwych skrzyżowaniach. Prawidłowe dokonanie tych osądów oznacza różnicę między bezpiecznym dotarciem do centrum handlowego a szpitala.
W technologii standardem jest dostępność na poziomie pięciu, a nawet sześciu dziewiątek – strona internetowa lub usługa jest dostępna 99,999% (lub 99,9999%) czasu. Koszt osiągnięcia pierwszych 99% nie jest tak wysoki. Oznacza to, że Twoja strona internetowa lub usługa może być niedostępna przez ponad trzy dni – 87,6 godziny – w ciągu roku. Jednak za każdą dodaną dziewiątkę na końcu, koszt osiągnięcia tego wzrasta wykładniczo. Do czasu, gdy osiągniesz 99,9999%, możesz pozwolić sobie tylko na 31,5 sekundy przestoju w ciągu roku. Wymaga to znacznie większego planowania i wysiłku, a oczywiście jest droższe. Osiągnięcie pierwszych 99% może nie być łatwe, ale proporcjonalnie jest to znacznie łatwiejsze i tańsze niż ta ostatnia mała frakcja.
365 X 24 X 60 minut = 525 600 minut w roku
Dostępność na poziomie 99% -> przestój przez 5256 minut, 87,6 godzin Dostępność na poziomie 99,9% -> przestój przez 526 minut, 8,76 godzin Dostępność na poziomie 99,99% -> 52 minuty, mniej niż 1 godzina Dostępność na poziomie 99,999% -> 5,2 minuty Dostępność na poziomie 99,9999% -> 0,52 minuty, około 31,5 sekund
Bez względu na to, jak blisko AI zbliża się do bycia wystarczająco dobra, zawsze istnieje ryzyko wypadków i ofiar śmiertelnych. Te ryzyka i konsekwencje zdarzają się codziennie, gdy za kierownicą siedzą ludzie. Nie wiem, jaki poziom wypadków i ofiar śmiertelnych będzie akceptowalny dla rządów, ale musisz myśleć, że musi być przynajmniej tak dobry jak u ludzi.
Powodem, dla którego tak trudno osiągnąć ten akceptowalny poziom bezpieczeństwa, jest to, że prowadzenie samochodu wiąże się ze znacznie większą ilością zmiennych niż szachy, a te zmienne NIE SĄ SKOŃCZONE. Pierwsze 95% lub 99% mogą być przewidywalne i łatwe do uwzględnienia. Jednak po pierwszych 99% jest tak wiele przypadków brzegowych, a każdy z nich może mieć pewne cechy wspólne, ale każdy jest unikalny; inne pojazdy na drodze prowadzone przez innych ludzi, zamknięcia dróg, roboty drogowe, wypadki, zdarzenia pogodowe. Ile razy jechałeś po drodze, która została wyasfaltowana, ale nie nałożono jeszcze farby do linii podziałowych na drodze. Znacznie trudniej jest sprawić, by Twój model AI był w stanie uwzględnić i rozpoznać te anomalie i przypadki brzegowe, a co ważniejsze, jak odpowiednio zareagować, nie wpadając w wypadek. Każdy przypadek brzegowy może mieć pewne cechy wspólne, ale rzadko są identyczne, co utrudnia AI zidentyfikowanie odpowiedniego sposobu reakcji.
AI nie może tworzyć oprogramowania, tylko kod
Tworzenie i utrzymanie oprogramowania ma znacznie więcej wspólnego z prowadzeniem samochodu niż z grą w szachy. Jest tu znacznie więcej zmiennych, a zasady opierają się na osądach. Możesz mieć pożądany wynik podczas budowy oprogramowania, ale jest mało prawdopodobne, że będzie on tak jednoznaczny jak w szachach. Oprogramowanie rzadko kiedy jest gotowe; dodawane są funkcje, naprawiane błędy; to ciągłe ćwiczenie. W przeciwieństwie do oprogramowania, raz wygrana lub przegrana partia szachów kończy się.
W rozwoju oprogramowania mamy narzędzie, które zbliża nasze projekty oprogramowania do ściśle kontrolowanego silnika zasad szachów: specyfikacje techniczne. W najlepszym przypadku specyfikacje opisują oczekiwane zachowania użytkowników i przepływy programu. Oto jak użytkownik kupuje e-kanapkę: kliknij ten przycisk, utwórz tę strukturę danych, uruchom tę usługę. Jednak rzadko dostajemy to, czego potrzebujemy. Zbyt często dostajemy listy życzeń jako specyfikacje funkcji, szkice na serwetkach i niejasne dokumenty wymagań, a następnie mówi się nam, abyśmy wydali nasze najlepsze osądy.
Co gorsza, wymagania zmieniają się lub są ignorowane. Ostatnio poproszono mnie o pomoc w zbudowaniu zespołu, który mógłby pomóc ludziom uzyskać informacje na temat problemów zdrowotnych związanych z COVID-19. Aplikacja miała być dla regionu globu, który nie ma niezawodnego WIFI. Zespół chciał, abym pomógł zbudować aplikację, która mogłaby przeprowadzać ankiety za pośrednictwem SMS-ów — wiadomości tekstowych na telefon. Początkowo byłem podekscytowany, że mogę się zaangażować.
Gdy zacząłem słuchać, co zespół myśli, że chce, zdałem sobie sprawę, że to będzie problem. To jedno, gdy firma handlowa prosi cię na skali od 1 do 10 o ocenę prawdopodobieństwa ponownych zakupów w ich sklepie. To zupełnie co innego, kiedy zadaje się wieloetapowe ankiety z pytaniami wielokrotnego wyboru na temat doświadczanych objawów możliwego zakażenia COVID-em. Nigdy nie powiedziałem nie, ale poruszyłem wszystkie możliwe punkty awarii w tym procesie i chciałem, aby zespół jasno zdefiniował, jak będziemy radzić sobie z przychodzącymi odpowiedziami na wszystkie pytania. Czy będą to liczby rozdzielone przecinkami przypisane do każdej odpowiedzi? Co się stanie, jeśli przesłana odpowiedź nie odpowiada żadnej z podanych opcji?
Po wszystkich tych pytaniach zespół doszedł do tego samego wniosku. Zdecydowaliśmy, że najlepiej będzie z tego zrezygnować. Wierzcie lub nie, powiedziałbym, że to właściwie udany wynik. Byłoby bardziej marnotrawne, gdybyśmy poszli dalej bez jasnego rozwiązania wszystkich potencjalnych błędów, gdy przesyłane są nieprawidłowe dane użytkownika.
Czy idea używania AI do tworzenia oprogramowania polega tylko na tym, by pozwolić tym samym interesariuszom rozmawiać bezpośrednio z komputerem, aby stworzyć ankietę opartą na SMS-ach? Czy AI będzie zadawać dociekliwe pytania na temat sposobu radzenia sobie ze wszystkimi możliwymi problemami zbierania danych ankietowych za pośrednictwem SMS-ów? Czy będzie uwzględniać wszystkie rzeczy, które my, ludzie, możemy zrobić nieprawidłowo po drodze i jak radzić sobie z tymi błędami?
Aby wyprodukować funkcjonalny kawałek oprogramowania z AI, musisz wiedzieć, czego chcesz i być w stanie jasno i precyzyjnie to zdefiniować. Są chwile, kiedy piszę oprogramowanie tylko dla siebie i nie zdaję sobie sprawy z niektórych trudności i wyzwań, dopóki nie zacznę pisać kodu.
W ciągu ostatniej dekady branża oprogramowania przeszła od metodyki wodospadowej do zwinnej. Wodospad dokładnie określa, czego chcesz, zanim napiszesz jakikolwiek kod, podczas gdy zwinność pozwala na wystarczającą elastyczność, aby można było dokonywać dostosowań po drodze.
Wiele projektów oprogramowania opartych na wodospadzie nie powiodło się, ponieważ interesariusze myśleli, że wiedzą, czego chcą, i myśleli, że mogą to dokładnie opisać i udokumentować, tylko po to, aby być bardzo rozczarowani, gdy finalny produkt został dostarczony. Zwinny rozwój oprogramowania ma być antidotum na ten proces.
AI może być najlepiej przystosowane do przepisywania oprogramowania, które już mamy, ale musimy je przepisać, aby używać nowszego sprzętu lub nowocześniejszego języka programowania. Wciąż jest wiele instytucji z oprogramowaniem napisanym w COBOL-u, ale jest mniej programistów uczących się, jak go używać. Jeśli dokładnie wiesz, czego chcesz, być może mógłbyś sprawić, aby AI wyprodukowała oprogramowanie szybciej i taniej niż zespół ludzkich programistów. Wierzę, że AI mogłaby stworzyć oprogramowanie, które już zostało stworzone, szybciej niż ludzcy programiści, ale dlatego, że ktoś po drodze wymyślił, co to oprogramowanie powinno robić.
AI mogłoby faktycznie całkiem dobrze radzić sobie z tworzeniem oprogramowania, używając procesu wodospadowego, który jest również nazywany marszem śmierci. Wiecie, kto jest okropny w wodospadzie? My, ludzie. I to nie chodzi o część, gdzie podpisane dokumenty są przekazywane zespołowi programistów, aby mogli napisać kod. Chodzi o wszystko przed tym. Sztuczna inteligencja może robić niezwykłe rzeczy, ale nie potrafi czytać w myślach ani powiedzieć ci, czego powinieneś chcieć.