Dlaczego oprogramowanie jest takie złe

To jeden z najstarszych dowcipów w Internecie, bez końca przesyłany ze skrzynki na skrzynkę e-mailową. Potentat oprogramowania – zwykle Bill Gates, ale czasami inny – wygłasza przemówienie. Potentat twierdzi, że gdyby przemysł samochodowy rozwinął się tak, jak przemysł oprogramowania, wszyscy jeździlibyśmy samochodami za 25 dolarów, które pokonują 1000 mil na galon. Na co dyrektor ds. samochodów odpowiada: Tak, a gdyby samochody były jak oprogramowanie, rozbijałyby się dwa razy dziennie bez powodu, a kiedy wezwałeś serwis, powiedzieliby ci, abyś ponownie zainstalować silnik.

Żart zawiera w sobie jedną z wielkich zagadek współczesnej technologii. W zadziwiająco krótkim czasie oprogramowanie stało się kluczowe w prawie każdym aspekcie współczesnego życia. Od skarbców bankowych po światła miejskie, od sieci telefonicznych po odtwarzacze DVD, od samochodowych poduszek powietrznych po systemy kontroli ruchu lotniczego, otaczający nas świat jest regulowany przez kod. Jednak wiele programów po prostu nie działa niezawodnie: zapytaj każdego, kto obserwował, jak ekran komputera świeci na niebiesko, co eliminuje godziny wysiłku. Jak twierdzą inżynierowie oprogramowania, zbyt często kod jest nadęty, brzydki, nieefektywny i źle zaprojektowany; nawet jeśli programy działają poprawnie, użytkownikom trudno je zrozumieć. Półki w księgarniach w całym kraju, uginające się pod ciężarem przypominających cegły podręczników, świadczą o trwałej dysfunkcjonalności oprogramowania.

Oprogramowanie jest dziś po prostu okropne, mówi Watts S. Humphrey, pracownik Instytutu Inżynierii Oprogramowania Carnegie Mellon University, który napisał kilka dobrze znanych książek na temat jakości oprogramowania. A cały czas jest coraz gorzej. Dobre oprogramowanie, w opinii Humphreya, jest użyteczne, niezawodne, wolne od wad, opłacalne i łatwe w utrzymaniu. A oprogramowanie to żadna z tych rzeczy. Nie możesz wyjąć czegoś z pudełka i wiedzieć, że to zadziała. Przez lata, zdaniem Edsgera W. Dijkstry, emerytowanego informatyka z University of Texas w Austin, przeciętny użytkownik komputera był obsługiwany tak słabo, że cały czas spodziewa się, że jego system będzie się zawieszał, a my jesteśmy świadkami ogromnej liczby ogólnoświatowa dystrybucja obarczonego błędami oprogramowania, za co powinniśmy się głęboko wstydzić.

Jim McCarthy jest bardziej hojny. Założyciel wraz z żoną Michele firmy szkoleniowej z zakresu jakości oprogramowania w Woodinville w stanie Waszyngton, McCarthy wierzy, że większość oprogramowania posiada niezbędne funkcje, które warto kupować, używać i adoptować. Ale, jak przyznaje, tylko ekstremalna użyteczność oprogramowania pozwala nam tolerować jego ogromne braki. McCarthy czasami zaczyna wykłady w swojej szkole od prezentacji w programie PowerPoint. Pierwszy slajd brzmi: Most Software Sucks.

Trudno przecenić wyjątkowość problemów oprogramowania. Kiedy inżynierowie motoryzacyjni omawiają samochody na rynku, nie mówią, że dzisiejsze pojazdy nie są lepsze niż dziesięć czy piętnaście lat temu. To samo dotyczy inżynierów lotnictwa: nikt nie twierdzi, że Boeing czy Airbus robią kiepskie samoloty. Inżynierowie elektrycy nie narzekają również, że chipy i obwody nie ulegają poprawie. Jak sugerował historyk inżynierii Henry Petroski w swojej książce z 1992 roku Ewolucja użytecznych rzeczy , ciągłe udoskonalanie jest zwykłą zasadą w technologii. Inżynierowie nieustannie zauważają niedociągnięcia w swoich projektach i stopniowo je naprawiają, co Petroski cierpko opisał jako następstwo niepowodzenia. W rezultacie produkty stopniowo się poprawiają.

Oprogramowanie, niestety, wydaje się inne. Można by oczekiwać, że 45-milionowy program, taki jak Windows XP, najnowszy system operacyjny Microsoftu, będzie miał kilka błędów. A inżynieria oprogramowania jest nowszą dyscypliną niż inżynieria mechaniczna czy elektryczna; pierwsze prawdziwe programy powstały dopiero 50 lat temu. Ale co jest zaskakujące – w rzeczywistości zdumiewające – to fakt, że wielu inżynierów oprogramowania uważa, że ​​jakość oprogramowania się nie poprawia. Mówią, że jeśli już, to jest coraz gorzej. To tak, jakby samochody wyprodukowane w Detroit w 2002 roku były mniej niezawodne niż te zbudowane w 1982 roku.

W miarę jak oprogramowanie staje się coraz ważniejsze, potencjalny wpływ złego kodu wzrośnie, tak jak uważa Peter G. Neumann, informatyk z SRI International, prywatnego centrum badawczo-rozwojowego w Menlo Park w Kalifornii. Tylko w ciągu ostatnich 15 lat defekty oprogramowania zniszczyły wystrzelenie europejskiego satelity, opóźniły o rok otwarcie niezwykle drogiego lotniska w Denver, zniszczyły misję NASA Mars, zabiły czterech marines w katastrofie helikoptera, skłoniły statek marynarki wojennej USA do zniszczenia cywilny samolot pasażerski i wyłączył systemy karetek w Londynie, co doprowadziło do śmierci nawet 30 osób. A z powodu naszej rosnącej zależności od sieci, Neumann mówi: Jesteśmy w znacznie gorszej sytuacji niż pięć lat temu. Ryzyko jest gorsze, a obrona nie tak dobra. Cofamy się – a to jest przerażające.

Niektóre firmy programistyczne odpowiadają na tę krytykę, ulepszając swoje procedury; Microsoft, urażony zarzutami, że jego produkty są wadliwe, publicznie przewodzi. Jednak problemy z jakością oprogramowania trwają tak długo i wydają się tak nierozerwalnie osadzone w kulturze oprogramowania, że ​​niektórzy programiści zaczynają myśleć, że jest to nie do pomyślenia. Ku własnemu zdumieniu ci ludzie zaczęli się zastanawiać, czy prawdziwym problemem z oprogramowaniem jest niewystarczająca liczba prawników.

Brak logiki

Microsoft wydał Windows XP 25 października 2001 r. Tego samego dnia, co może być rekordem, firma opublikowała 18 megabajtów poprawek w swojej witrynie sieci Web: poprawki błędów, aktualizacje dotyczące zgodności i ulepszenia. Dwie łatki naprawiły ważne luki w zabezpieczeniach. A raczej jeden z nich to zrobił; druga łatka nie działała. Microsoft doradzał (i nadal radzi) użytkownikom tworzenie kopii zapasowych krytycznych plików przed zainstalowaniem poprawek. Nabywcy domowej wersji systemu Windows XP odkryli jednak, że system nie zapewnia możliwości przywrócenia tych plików kopii zapasowej, jeśli coś pójdzie nie tak. Jak uprzejmie wyjaśniono w internetowej bazie wiedzy Microsoftu, specjalne dyskietki z kopiami zapasowymi utworzone przez system Windows XP Home nie działają w systemie Windows XP Home.

Krytycy twierdzą, że takie wpadki są jedynie powierzchownymi potknięciami – oznakami, że twórcy oprogramowania byli zbyt pospieszni lub zbyt nieostrożni, by naprawić oczywiste defekty. Według R.A. Downesa z Radsoft, firmy konsultingowej ds. oprogramowania, prawdziwe problemy leżą w podstawowym projekcie oprogramowania. A raczej jego brak projektowania. Popularne oprogramowanie Microsoft Visual Studio jest przykładem sposobu myślenia Downesa. Downes odkrył, że po prostu najechanie kursorem na okno programu Visual Studio w niewidoczny sposób zasypuje jednostkę centralną tysiącami niepotrzebnych wiadomości, mimo że program nic nie robi. To kataklizm. To totalny chaos, narzeka.

Problemem, zdaniem Dana Wallacha, informatyka z Rice University, nie jest bezsensowne ubijanie procesora – w końcu, jak zauważa, moc obliczeniowa jest tania. Oprogramowanie Microsoft nie jest też szczególnie wadliwe; krytycy często posługują się produktami firmy jako przykładami bardziej dlatego, że są znajome, niż dlatego, że są wyjątkowo złe. Zamiast tego, zdaniem Wallacha, kwitnące, brzęczące zamieszanie w Visual Studio i wielu innych programach pokazuje, w jaki sposób techniki pisania oprogramowania nie nadążają za wybuchowym wzrostem jego złożoności.

Programiści piszą kod w językach takich jak Java, C i C++, które mogą być odczytywane przez ludzi. Wyspecjalizowane programy znane jako kompilatory przekształcają ten kod w ciągi jedynek i zer używane przez komputery. Co ważne, kompilatory odmawiają kompilacji kodu z oczywistymi problemami — zamiast tego wyrzucają komunikaty o błędach. Do lat 70. kompilatory siedziały na dużych komputerach mainframe, które często rezerwowano z kilkudniowym lub tygodniowym wyprzedzeniem. Nie chcąc, by błędy powodowały opóźnienia, koderzy – którzy na początku byli zwykle szkoleni na matematyków lub fizyków – spóźniali się w swoich biurach, wyczerpująco sprawdzając swoją pracę. Pisanie oprogramowania przypominało pisanie artykułów naukowych. Rygor, dokumentacja i weryfikacja recenzentów były zwyczajem.

Jednak wraz z upowszechnieniem się komputerów zmieniły się postawy. Zamiast skrupulatnie planować kod, programiści spędzali całą noc na sesjach hakerskich zawierających kofeinę, stale odbijając wyniki od kompilatora. Kompilator raz za razem wypluwał komunikaty o błędach; programiści naprawiali błędy jeden po drugim, dopóki oprogramowanie nie skompilowało się poprawnie. Dzisiejsze podejście jest takie, że można napisać dowolny niedbały fragment kodu, a kompilator uruchomi diagnostykę, mówi Neumann z SRI. Jeśli nie wypluwa komunikatu o błędzie, musi być zrobione poprawnie, prawda?

Jednak wraz ze wzrostem rozmiarów i złożoności programów ograniczenia tego kodu i podejścia do naprawy stały się oczywiste. Według wieloletniego badania 13 000 programów, przeprowadzonego przez Humphreya z Carnegie Mellon, zawodowi programiści popełniają średnio od 100 do 150 błędów w każdym tysiącu linijek kodu, który napiszą. Korzystając z danych Humphreya, biznesowy system operacyjny Windows NT 4, z 16 milionami linii kodu, zostałby napisany z około dwoma milionami błędów. Większość byłaby zbyt mała, by wywrzeć jakikolwiek efekt, ale niektóre – wiele tysięcy – spowodowałoby poważne problemy.

Oczywiście Microsoft wyczerpująco przetestował NT 4 przed wydaniem, ale w niemal każdej fazie testów znajdziesz mniej niż połowę defektów, mówi Humphrey. Gdyby Microsoft przeszedł cztery rundy testów, co jest kosztowną i czasochłonną procedurą, firma znalazłaby co najwyżej 15 z 16 błędów. Humphrey mówi, że przez to zostaniesz z około pięcioma defektami na tysiąc linii kodu. To bardzo mało, ale oprogramowanie nadal zawierałoby aż 80 000 błędów.

Inżynierowie oprogramowania wiedzą, że ich kod jest często pełen luk i od dawna szukają nowych technologii, aby im zapobiegać. Aby zarządzać coraz bardziej rozbudowanymi projektami, takimi jak na przykład Windows, opracowali różne techniki, z których być może najbardziej znaną jest projektowanie oparte na komponentach. Podobnie jak domy budowane są ze znormalizowanych dwóch na cztery i osprzętu elektrycznego, programy oparte na komponentach są budowane z modułowych, wymiennych elementów: przykładem jest prawie identyczny pasek menu na każdym programie Windows lub Macintosh. Takie ustandaryzowane komponenty, według Wallacha, to nie tylko dobra praktyka inżynierska, to jedyny sposób na to, aby coś wielkości Microsoft Office w ogóle działało. Microsoft, jak mówi, był wczesnym, agresywnym propagatorem tego podejścia – to najlepsza decyzja inżynieryjna, jaką kiedykolwiek podjęli.

Niestety, krytycy twierdzą, że komponenty są często sklejane bez prawdziwego planu centralnego – tak jakby wykonawcy próbowali wznosić duże konstrukcje bez planów. To niewiarygodne, mówi Humphrey, że projekt dużych projektów oprogramowania to czasem tylko kilka bąbelków na odwrocie koperty. Co gorsza, ze względów marketingowych firmy łączą jak najwięcej funkcji w nowym oprogramowaniu, przeciwdziałając korzyściom wynikającym z budowy modułowej. Najbardziej rozpowszechnionym przykładem jest sam Windows, o którym Bill Gates zeznał podczas kwietniowej sesji procesu antymonopolowego Microsoftu, po prostu nie działałby, gdyby klienci usunęli poszczególne komponenty, takie jak przeglądarki, menedżery plików czy programy pocztowe. To niesamowite twierdzenie, mówi Neumann. Oznacza to, że nie ma żadnej struktury, architektury, rymu ani powodu w sposobie, w jaki zbudowali te systemy, poza tym, aby były jak najbardziej zgrupowane, tak aby jeśli usuniesz jakąkolwiek część, wszystko się nie powiedzie.

Krytycy twierdzą, że niedostateczny projekt produktów końcowych odzwierciedla nieodpowiednie planowanie w procesie ich tworzenia. Według badania przeprowadzonego przez Standish Group, firmę konsultingową z West Yarmouth w stanie Massachusetts, komercyjne projekty oprogramowania są tak źle zaplanowane i zarządzane, że w 2000 r. prawie jedna czwarta została całkowicie anulowana, nie tworząc żadnego produktu końcowego. Anulowane projekty kosztowały firmy 67 miliardów dolarów; przekroczenia innych projektów przyniosły kolejne 21 miliardów dolarów. Ale ponieważ kod i poprawka prowadzą do tak obszernych, kosztownych rund testów, nawet udane projekty mogą być szalenie nieefektywne. Niesamowicie, projekty oprogramowania często poświęcają 80 procent budżetów przeznaczonych na naprawę usterek, które sami stworzyli — liczba ta nie obejmuje jeszcze bardziej kosztownego procesu zapewniania wsparcia produktu i opracowywania poprawek dla problemów wykrytych po wydaniu.

Testowanie systemu trwa prawie połowę procesu, mówi Humphrey. A nawet kiedy w końcu to zadziała, nadal nie ma projektu. W konsekwencji oprogramowanie nie może być aktualizowane ani ulepszane z jakąkolwiek gwarancją, że aktualizacje lub ulepszenia nie spowodują poważnych usterek. W ten sposób wszędzie projektuje się i buduje oprogramowanie – tak jest w statkach kosmicznych, na litość boską.

Czy oprogramowanie to przypadek szczególny?

Potencjalne ryzyko związane ze złym oprogramowaniem zostało ponuro zilustrowane w latach 1985-1987, kiedy sterowana komputerowo maszyna do radioterapii, wyprodukowana przez wspieraną przez rząd Atomic Energy of Canada, masowo przedawkowała pacjentów w Stanach Zjednoczonych i Kanadzie, zabijając co najmniej trzech. W wyczerpującym badaniu Nancy Leveson, obecnie informatyk z MIT, przypisała znaczną część winy nieodpowiednim praktykom inżynieryjnym producenta. Ponieważ program służący do ustawiania natężenia promieniowania nie został dokładnie zaprojektowany ani przetestowany, proste błędy w pisowni wywoływały śmiertelne wybuchy.

Pomimo tego tragicznego doświadczenia, podobne maszyny obsługujące oprogramowanie firmy Multidata Systems International z St. Louis, w latach 2000 i 2001 masowo przedawkowały pacjentów w Panamie, co doprowadziło do kolejnych ośmiu zgonów. Zespół z Międzynarodowej Agencji Energii Atomowej przypisał zgony wprowadzaniu danych w sposób, którego programiści nie przewidzieli. Jak zauważa Leveson, proste błędy wprowadzania danych nie powinny mieć śmiertelnych konsekwencji. Więc ta awaria również może być spowodowana nieodpowiednim oprogramowaniem.

Eksperci od programowania są zgodni, że takie katastrofy są niepokojąco powszechne. Weźmy pod uwagę Mars Climate Orbiter i Polar Lander, oba zniszczone w 1999 roku przez znane, łatwo zapobiegające błędom kodowania. Jednak niektórzy twierdzą, że oprogramowania po prostu nie można oceniać, mierzyć i ulepszać w taki sam sposób, jak innych produktów inżynieryjnych. To tylko fakt, że są rzeczy, które inni inżynierowie mogą zrobić, a my nie możemy zrobić, mówi Shari Lawrence Pfleeger, starszy badacz w think tanku Rand w Waszyngtonie i autorka tomu z 2001 roku. Inżynieria oprogramowania: teoria i praktyka . Jeśli most wytrzyma ciężar 500 i 50 000 kg, zauważa Pfleeger, inżynierowie mogą założyć, że utrzyma wszystkie wartości pomiędzy nimi. Mówi, że z oprogramowaniem nie mogę przyjąć takiego założenia – nie mogę interpolować.

Co więcej, twórcy oprogramowania pracują pod nadzwyczajnymi wymaganiami. Ford i General Motors od dziesięcioleci produkują ten sam produkt – czterokołowe skrzynie z silnikiem spalinowym. W rezultacie, jak mówi Charles H. Connell, były główny inżynier Lotus Development (obecnie część IBM), udało im się stopniowo ulepszać swoje produkty. Jednak firmy programistyczne są nieustannie proszone o tworzenie produktów — przeglądarek internetowych na początku lat 90., nowych interfejsów telefonów komórkowych — w przeciwieństwie do niczego, co widziano wcześniej. To tak, jakby producent samochodów powiedział: „W tym roku zrobimy rakietę zamiast samochodu” – mówi Connell. Oczywiście będą mieli problemy.

Klasyczny dylemat w oprogramowaniu polega na tym, że ludzie ciągle chcą coraz więcej i więcej rzeczy, mówi Nathan Myhrvold, były dyrektor ds. technologii w Microsoft. Niestety, zauważa, nieustanne zapotrzebowanie na nowości sprawia, że ​​oprogramowanie jest zawsze w fazie rozwoju, kiedy produkty są z natury mniej niezawodne. Jak mówi, w 1983 roku Microsoft Word miał tylko 27 000 linii kodu. Problem polega na tym, że nie zrobił zbyt wiele, czego dzisiejsi klienci nie zaakceptowaliby. Gdyby Microsoft nie pompował Worda nowymi funkcjami, produkt już by nie istniał.

Użytkownicy są niesamowicie nieświadomi, dodaje Myhrvold. Jak mówi, w firmie Microsoft klienci korporacyjni często domagali się od firmy jednoczesnego dodawania nowych funkcji i zaprzestania dodawania nowych funkcji. Dosłownie usłyszałem to jednym tchem, jednym zdaniem. Nie jesteśmy pewni, dlaczego powinniśmy uaktualnić do tej nowej wersji — zawiera wszystkie te rzeczy, których nie chcemy — i kiedy zamierzasz umieścić te trzy rzeczy?” A ty mówisz: Coo?” Sardoniczne podsumowanie Myhrvolda: Oprogramowanie jest do bani, ponieważ użytkownicy tego wymagają.

Wyższe standardy

W styczniu Bill Gates zaapelował do pracowników firmy Microsoft o uczynienie niezawodnym i bezpiecznym przetwarzaniem swoim najwyższym priorytetem. W tym, co firma określiła jako jedną z najważniejszych inicjatyw od lat, Gates zażądał od Microsoftu radykalnego zmniejszenia liczby defektów w swoich produktach. Miesiąc później firma podjęła bezprecedensowy krok, zawieszając cały nowy kod na prawie dwa miesiące. Zamiast tego zgromadził tysiąc programistów na raz, aby wziąć udział w masowych sesjach szkoleniowych dotyczących niezawodności i bezpieczeństwa. Korzystając z ogromnych ekranów w gigantycznym audytorium, dyrektorzy firmy wyświetlali zawstydzające fragmenty wadliwego kodu wyprodukowanego przez widzów.

Inicjatywa Gatesa została najwyraźniej zainspirowana falą krytyki, która ogarnęła Microsoft w lipcu 2001 r., kiedy przepełnienie bufora – od dawna znany rodzaj błędu – w oprogramowaniu serwera internetowego Internet Information Services pozwolił robakowi Code Red na zaatakowanie tysięcy klientów korporacyjnych. (W przypadku przepełnienia bufora program otrzymuje więcej danych niż oczekiwano — tak jakby miejsce na kod pocztowy zostało wypełnione 50-cyfrową liczbą. W komputerze dodatkowe informacje rozleją się na sąsiednie części pamięci, uszkadzając lub nadpisując dane tam znajdują się, chyba że zostaną starannie zablokowane.) Dwa miesiące później robak Nimda wykorzystał inne luki w oprogramowaniu, aby zaatakować kolejne tysiące maszyn.

Zmęczeni takimi doświadczeniami twórcy oprogramowania coraz bardziej zwracają uwagę na jakość. Nawet gdy Gates gromadził swoje wojska, think tanki, takie jak Kestrel Institute z Palo Alto w Kalifornii, opracowywały zestawy narzędzi do programowania poprawnych do konstrukcji, które niemal zmuszają programistów do pisania niezawodnych programów ( patrz Pierwsza pomoc w przypadku nieprawidłowego kodu ). Według Amitabha Srivastava, szefa Centrum Badawczego Produktywności Programistów w samym Microsoft, programiści pracują z nowymi językami wyższego poziomu, takimi jak C#, które nie pozwalają na pewne błędy. W maju Microsoft współtworzył z NASA i 16 innymi firmami konsorcjum Sustainable Computing Consortium o wartości 30 milionów dolarów z siedzibą w Carnegie Mellon, aby promować standardowe sposoby pomiaru i poprawy niezawodności oprogramowania. Wysiłki w zakresie kontroli jakości mogą się sowicie opłacić: pomagając Lockheed Martin w modernizacji oprogramowania w swoim samolocie C130J, Praxis Critical Systems z Bath w Anglii zastosowała takie metody, aby obniżyć koszty rozwoju o 80 procent, jednocześnie tworząc oprogramowanie, które zdało rygorystyczne egzaminy Federalnej Administracji Lotnictwa bardzo mało błędów.

ukryć