Człowiek vs Komputer - ebook

Wprowadzenie

WPROWADZENIE

Nie ulega wątpliwości, że komputery zarządzają działaniem naszego świata – mają ostatnie słowo w każdej kwestii, od ceny twojej porannej kawy po globalne kursy wymiany walut. Rządy na całym świecie coraz szybciej się digitalizują. Miejsca pracy są zastępowane przez algorytmy. Wszechobecna automatyzacja w połączeniu z inteligentnym marketingiem sprawia, że zaczynamy naprawdę wierzyć w to, iż nasze telefony, telewizory czy nawet samochody stają się „inteligentne”. A przecież wszystkie te systemy komputerowe zostały stworzone przez człowieka – istotę o dobrych intencjach, ale niedoskonałą i nieobiektywną, mądrą, ale roztargnioną, snującą wielkie plany, ale działającą pod presją czasu. Digitalizacja jakiegoś zadania nie oznacza, że unikniemy jakichkolwiek błędów – za to gwarantuje, że jeśli już błąd się zdarzy, to będzie działać na skalę masową.

Ta książka opowiada o ludziach złapanych w pułapkę między błędnymi założeniami a logiką binarną. Poznamy historię osób niewidzialnych dla komputerów, dowiemy się, jak domyślne hasło spowodowało apokalipsę zombie i dlaczego linie lotnicze rozdają czasami darmowe bilety. To także książka o tym, jak zapobiegać tego typu głupim problemom, unikać ich albo przynajmniej redukować ich wpływy.

Jako zawodowy programista jestem bardziej niż statystyczny człowiek odpowiedzialny za popychanie cywilizacji w kierunku cyfrowej apokalipsy. Z drugiej strony wystarczająco często mam do czynienia z końcowym efektem błędów w programach komputerowych, aby w pełni rozumieć ból, jaki mogą one spowodować. Ta książka jest próbą zwiększenia świadomości na temat często spotykanych, niebezpiecznych błędów i pomyłek, którym łatwo można zapobiegać. I – co może ważniejsze – chciałbym w ten sposób pomóc zwykłym ludziom przeciwstawiać się tym problemom.

DLA NIECIERPLIWYCH

Część zatytułowana „Odwrócone twierdzenie o małpach”, zaczynająca się w rozdz. „Unikod śmierci”, zawiera listy kontrolne i heurystyki, które można wykorzystać przy pisaniu programów, ich analizie i testowaniu.

Wiedza na temat błędów najczęściej popełnianych przez programistów pomogła mi założyć konto w banku na lepszych warunkach, niż zaproponował system, rozwiązać tajemnicę wygórowanych rachunków za media i odzyskać kartę płatniczą zatrzymaną przez wkurzony bankomat. Kiedy następnym razem uderzysz głową w cyfrowy mur, historie opisane w tej książce pomogą ci lepiej zrozumieć, co się właściwie dzieje, i wskażą, gdzie należałoby szukać źródeł problemu. A w najgorszym razie, jeśli będzie ci się wydawało, że masz do czynienia ze złowrogą, czarną magią, moje opowieści pozwolą ci przynajmniej dostrzec jaśniejszą stronę binarnego chaosu.

A dla was, moi koledzy programiści, książka ta będzie – mam nadzieję – okazją do wyrobienia w sobie odrobiny współczucia dla ludzi cierpiących z powodu naszych błędów, bo to w końcu oni ostatecznie płacą ich cenę. Moją intencją nie było stworzenie wyczerpującego przewodnika po jakości oprogramowania, a raczej zilustrowanie typowych, częstych błędów za pomocą zapadających w pamięć historyjek. Warto jednak dodać, że w końcowej części książki znajdziecie kilka przydatnych, praktycznych porad opracowanych na podstawie tych historii, dzięki którym możemy tworzyć oprogramowanie mniej podatne na błędy i pomyłki.SZTUCZNA, ALE NIE INTELIGENCJA

Nasze życie jest w coraz większym stopniu śledzone, monitorowane i kategoryzowane przez oprogramowanie, które zasila ogromny ocean danych wciąż aktualizowanym strumieniem informacji. W tym nowym, wspaniałym świecie ludzie nie są w stanie radzić sobie z ich nadmiarem. Rządy i firmy polegają na komputerach, aby automatycznie wykrywać oszustwa, przewidywać nasze zachowania i egzekwować prawo. Maszyny, którym obce jest pojęcie elastyczności, niewiele mądrzejsze od lodówek, podejmują decyzje, od których zależy kształt ludzkiego życia.

Problem polega na tym, że wszystkie te przepisy podatkowe, prawa i regulaminy naszego świata nie zostały stworzone z myślą o automatyzacji. Są one niejednoznaczne, uzależnione od kontekstu, pełne luk, wyjątków i szczególnych przypadków. Cała profesja prawnicza ma się świetnie właśnie dlatego, że prawo nie jest binarne – i nie wygląda na to, żeby w najbliższym czasie prawnicy musieli odstąpić swój kawałek tortu robotom. A w dodatku – rzecz prosta – twórcy oprogramowania rzadko mają wiedzę niezbędną do interpretacji nawet tych przepisów, które są precyzyjnie zdefiniowane.

Historie opisane w tej części książki pokazują, co się dzieje, kiedy nieelastyczne algorytmy podejmujące decyzje zderzają się z różnorodnością prawdziwego życia.Kamery monitoringu i oprogramowanie umożliwiające odczytywanie tablic rejestracyjnych zdecydowanie ułatwiają nadzorowanie ruchu ulicznego, pobieranie opłat drogowych i wystawianie mandatów. Jeśli jednak komputer nie jest w stanie odczytać treści tablic, cały system można bardzo łatwo obejść. Choć Dolina Krzemowa reprezentuje awangardę współczesnej technologii, amerykański stan Kalifornia tylko w 2013 roku stracił ponad 12 milionów dolarów z tytułu opłat drogowych wyłącznie dlatego, że komputery nie były w stanie obciążyć nimi kierowców, których samochody nie miały tablic rejestracyjnych. W większości miejsc na świecie istnieje obowiązek posiadania takich tablic na pojeździe, ale kalifornijskie prawo o ruchu drogowym, artykuł 4456, sekcja C2, pozwala na to, aby nowy samochód jeździł bez nich przez pierwsze 90 dni. Jedną z osób słynnych z wykorzystywania tej luki prawnej był Steve Jobs, który podobno co kilka miesięcy brał w leasing nowego mercedesa SL55 AMG – więc mógł nim jeździć anonimowo. Ustawa AB-516 ma zlikwidować taką możliwość już w 2019 roku, ale po drogach nadal będą jeździć samochody z nieczytelnymi tablicami lub w ogóle ich pozbawione. A kiedy policjanci z drogówki próbują wystawić mandat takiemu pojazdowi – komputery dostają szału.

Najbardziej znanym przykładem takiej sytuacji jest historia niejakiego Roberta Barboura z Los Angeles. Barbour uwielbiał żeglowanie i chciał mieć w swoim samochodzie zindywidualizowane tablice rejestracyjne związane z tym hobby. Najbardziej podobały mu się rejestracje z napisami BOATING (dosł. pływanie łodzią, wodniactwo) albo SAILING (żeglarstwo). Żadnej innej nie chciał, ale formularz, który musiał wypełnić, miał trzy rubryki na propozycje, z których żadna nie mogła pozostać pusta. W trzeciej rubryce Barbour napisał zatem „no plate” (bez tablic, brak tablic). Na skutek niemal proroczej pomyłki, która ciągnęła się przez kolejne kilka miesięcy, komputer w wydziale ruchu drogowego zinterpretował dosłownie coś, co każdy człowiek bez trudu uznałby po prostu za brakującą informację. Okazało się, że pierwsze dwie propozycje pana Barboura są już zajęte – więc otrzymał on tablice według trzeciego wyboru. Tablice z napisem „brak tablic” to było coś naprawdę oryginalnego, toteż Barbour nie zaprotestował. Niestety, radość skończyła się po miesiącu, kiedy nasz bohater zaczął dostawać pocztą mandaty za złe parkowanie z całej Kalifornii. Kiedy jakiś nieprawidłowo zaparkowany pojazd nie miał tablic rejestracyjnych, policjant mimo wszystko musiał wystawić mandat – ale komputery nie akceptowały pustych pól na formularzach. Policjanci musieli sobie z tym jakoś radzić, a że byli ludźmi, wielu z nich wpadało na podobny pomysł jak Robert Barbour i pisało w formularzu „brak tablic”. W normalnej sytuacji takie mandaty pewnie trafiałyby do kosza, ale nagle okazało się, że komputery znają tablice rejestracyjne, do których ten wpis pasuje. Do chwili, kiedy kłopotami pana Barboura zainteresowały się media, dostawał on już co miesiąc ponad 2 tysiące mandatów za nieprawidłowe parkowanie.

Kiedy kalifornijski wydział komunikacji zrozumiał wreszcie, co się naprawdę stało, poprosił policjantów, aby zaprzestali wpisywania hasła „no plate” w formularze mandatów w razie trafienia na samochody bez tablic. Zamiast poprawić system komputerowy – tak aby akceptował mandaty bez podania rejestracji pojazdu – zaproponowano inne rozwiązanie problemu. Policjanci zostali oficjalnie wezwani, żeby w takich sytuacjach wpisywali w formularz hasło „missing” (brak). Co z kolei natychmiast przysporzyło mnóstwa problemów niejakiemu Andrew Burgowi z Marina del Rey. Bo pan Burg – kto by pomyślał – miał na swoim samochodzie zindywidualizowane tablice rejestracyjne ze słowem MISSING¹. Podobnych kłopotów doświadczyła pani Carol Schroeder z Florydy, która zamówiła tablice z napisem NOTAG i wkrótce dostała wezwanie do zapłacenia ponad 8 tysięcy dolarów zaległych mandatów². Podobne doświadczenia miał Ralph August z miejscowości Westchester, na którego rejestracji widniało słowo UNKNOWN (nieznany). Z kolei Scottie Roberson z Huntville w Alabamie zdecydował się na tablice będące połączeniem jego szczęśliwej liczby (7) i pseudonimu: Racer X. Niestety, wpis „XXXXXXX” był popularną wśród policjantów z pobliskiego Birmingham metodą oznaczania brakujących tablic… Roberson dostał wezwania do zapłaty mandatów na łączną sumę ponad 19 tysięcy dolarów i dopiero interwencja mediów zmusiła miejscowe władze do zmierzenia się z tym problemem.

Jednak za absolutnego zwycięzcę w tej kategorii należy uznać Richarda Turnera z Beverly Hills, który miał tablice z napisem VOID (brak)³. Kilka lat po tym, jak zdecydował się na taką rejestrację, lokalny wydział komunikacji zmienił zasady postępowania z mandatami unieważnionymi przez sąd – zaczął oznaczać je jako „unieważnione”. Oczywiście oprogramowanie nie zostało zmienione odpowiednio szybko, więc wszystkie mandaty oznaczone jako VOID zaczęły przychodzić na adres pana Turnera…

Takie pomyłki zachodzą wtedy, kiedy komputer wymaga, aby ludzie dostarczyli mu jakieś informacje, które w rzeczywistości są niedostępne lub po prostu nie istnieją, więc ludzie wymyślają obejście problemu. Prawdziwa zabawa zaczyna się, gdy kilka systemów musi się wymienić między sobą informacjami i okazuje się, że w każdym z nich użyto innego obejścia. Coś co w jednym systemie jest symbolem zastępczym, w innym staje się poprawnymi danymi, a problem zaczyna się mnożyć i rozprzestrzeniać.

Problemy ze znacznikami danych mogą przez długi czas pozostawać uśpione. Kiedy wszystkie zapisy, które z założenia miały się do niczego nie odnosić, nagle zaczną pasować do jakichś znaczących danych – na przykład gdy ktoś ma tablice rejestracyjne z napisem „brak tablic” – zaczyna się chaos.

Jednocześnie pojawia się problem algorytmów niepotrzebnie ignorujących dane z innych systemów, które w rzeczywistości powinny być akceptowane. To może rodzić jeszcze poważniejsze problemy – o czym opowiada kolejna historia.Był 10 lipca 2010 roku, kiedy ulicą Penrose w Sun Valley, w Kalifornii pędził samochód. Za kierownicą siedział 28-letni wówczas Javier Joseph Rueda, który niedawno wyszedł z więzienia. Był jednym z 10 tysięcy ludzi, którzy dostali zgodę na wcześniejsze zwolnienie warunkowe, bo komputery uznały, że są minimalnym zagrożeniem dla społeczeństwa, a ryzyko, że wrócą na drogę przestępstwa, jest tak małe, że nie muszą nawet zgłaszać się do swojego kuratora. Wcześniej tego samego dnia pewien policjant próbował zatrzymać Ruedę, podejrzewając, że prowadzi on samochód po alkoholu. Jeśli osoba na zwolnieniu warunkowym zostanie złapana na przestępstwie, musi wrócić za kraty – dlatego Javier postawił wszystko na jedną kartę i próbował uciec przed patrolem. Niestety, pędzące za nim samochody policyjne na sygnale nie chciały odpuścić. Kiedy pościg zbliżał się do ulicy Penrose, Rueda rozważał już różne wyjścia z sytuacji. W końcu zatrzymał się, wyskoczył z samochodu, zwrócił się w stronę ścigających go policjantów i wyciągnął dwa pistolety półautomatyczne.

Kalifornia miała poważny problem z przepełnionymi więzieniami jeszcze zanim w 2007 roku pękła bańka kredytowa i zaczął się kryzys finansowy. Stanowe zakłady karne mogły pomieścić łącznie około 80 tysięcy skazanych, ale w 2009 roku było ich niemal dwukrotnie więcej. Sąd federalny nakazał zmniejszenie przeludnienia w więzieniach o 30 tysięcy osób w ciągu dwóch lat, ponieważ części więźniów nie dało się zapewnić nawet podstawowej opieki medycznej. Amerykański Sąd Najwyższy podtrzymał później tę decyzję, argumentując, że warunki w zakładach karnych były tak złe, iż naruszały konstytucyjny zakaz stosowania okrutnych kar. Władze stanowe zostały zatem postawione w obliczu niemal nierozwiązywalnego problemu: musiały radzić sobie ze znacznie większą liczbą osób na zwolnieniach warunkowych, mimo że nie miały ani więcej ludzi, ani większych funduszy niż wcześniej.

Sposobem na poradzenie sobie z tym kryzysem było wprowadzenie w 2010 roku zwolnień warunkowych bez obowiązku regularnego zgłaszania się u swojego kuratora (tzw. non-revocable parole, NRP). Tego typu zwolnieniami zostali objęci drobni przestępcy, niestanowiący dużego ryzyka: nie byli członkami gangów, nie popełniali przestępstw z użyciem przemocy. Dzięki temu kuratorzy i policja mieli więcej czasu na zajmowanie się tymi przestępcami na zwolnieniu warunkowym, którzy stwarzali większe ryzyko problemów. Aby w krótkim czasie dokonać selekcji tysięcy więźniów z szansą na zwolnienie warunkowe, stan sięgnął po eksperymentalne oprogramowanie o nazwie PVDMI (Parole Violation Decision-Making Instrument – narzędzie do podejmowania decyzji o naruszaniu warunków zwolnienia warunkowego). Program PVDMI wskazał około 10 tysięcy ludzi, którzy mogli wyjść na wcześniejsze zwolnienie warunkowe. Jednym z tych szczęśliwców był Javier Rueda.

Po odsiedzeniu zaledwie dwóch lat z dziesięcioletniego wyroku Rueda został uznany przez PVDMI za osobę, która raczej nie wróci na drogę łamania prawa – a w każdym razie nie popełni przestępstwa z użyciem przemocy. Stało się tak, mimo że był on znanym członkiem gangu, a w historii jego przestępstw były między innymi napaści na policjantów i nielegalne posiadanie broni. Patrol policji ścigający Ruedę po ulicy Penrose szybko przekonał się, czy był on więźniem „niskiego ryzyka”. Jeden ze stróżów prawa został postrzelony, ale pozostali odpowiedzieli ogniem. Ostatecznie Javierowi udało się uniknąć powrotu do więzienia – choć chyba zapłacił za to wyższą cenę, niż się spodziewał…

Dziennikarze – jak zwykle – spisali się lepiej niż komputery. Dwa miesiące przed tym incydentem dziennik „San Diego Union-Tribune” ostrzegał przed skutkami zbyt wczesnego wprowadzania programu. Według autorów tekstu bez mała 650 więźniów zakwalifikowanych do zwolnień warunkowych typu NRP w rzeczywistości należało do grupy wysokiego ryzyka: byli wśród nich między innymi członkowie gangów i agresywni gwałciciele. Przypadek Javiera Ruedy sprawił, że kilkaset spraw zostało ręcznie sprawdzonych, a stanowe Biuro Inspektora Generalnego przyznało się do popełnionych błędów. Ponowna analiza wykazała, że wśród zwolnionych więźniów było ponad 450, którzy stwarzali wysokie ryzyko popełniania przestępstw z użyciem przemocy i ponad 1000 takich, którzy mogli popełniać przestępstwa związane z handlem narkotykami.

Okazało się, że oprogramowanie PVDMI nie miało dostępu do historii aresztowań wielu osadzonych, a z powodu błędów w programie osoby z niepełnym profilem zostały sklasyfikowane jako przypadki niskiego ryzyka. Analiza wykazała, że poziom tego rodzaju błędów wynosił aż 15%.

Departament więziennictwa stanu Waszyngton popełnił podobną pomyłkę, wypuszczając zbyt wcześnie ponad 3 tysiące więźniów. Tym razem za błąd był odpowiedzialny zbyt przyjazny system komputerowy, który skracał skazanym wyroki za dobre sprawowanie. Niektóre kategorie przestępstw wykluczały wprawdzie taką możliwość, ale okazało się, że z powodu błędu w programie „punkty” za dobre sprawowanie były przyznawane także tym więźniom, którzy nie powinni byli ich otrzymać. W rezultacie około 3% więźniów zostało wypuszczonych o ponad dziesięć lat za wcześnie. Błąd w programie zauważono w 2012 roku, kiedy rodzina pewnej ofiary przestępstwa złożyła w departamencie więziennictwa skargę na przedwczesne uwolnienie sprawcy. Osoby analizujące sprawę „ręcznie” policzyły, kiedy przestępca rzeczywiście powinien być zwolniony – i zauważyły błąd, ale jego naprawienie zajęło ponad trzy lata. W tym czasie ponad setka przedwcześnie zwolnionych została ponownie aresztowana za przestępstwa, które popełnili, będąc na zwolnieniu warunkowym. Kiedy media zaczęły naciskać na polityków, pracę stracił Dan Pacholke, sekretarz departamentu więziennictwa – niestety, byli ludzie, którzy zapłacili za ten błąd znacznie wyższą cenę. 17-letni wówczas Caesar Medina i 35-letnia Lindsay Hill, matka dwojga dzieci, zostali zamordowani przez wypuszczonych więźniów, którzy zgodnie z wyrokami sądowymi powinni nadal przebywać za kratami.

Osoby projektujące te systemy komputerowe popełniły – patrząc z perspektywy czasu – głupie błędy. Niestety, ich konsekwencje były bardzo poważne. Jeden program uznawał brak historii aresztowań za potwierdzenie, że wszystko jest w porządku; drugi uznał, że wszystko jest w porządku, mimo że miał dostęp do odpowiednich dokumentów.

Czasami zbyt bogata historia także może być problemem. Kiedy 30 stycznia 2016 roku Steven Lawrence Wright opuszczał centrum przyjęć więźniów w Los Angeles, nie mógł uwierzyć własnemu szczęściu. Wright został uznany za winnego usiłowania zabójstwa i w więzieniu oczekiwał na wydanie wyroku. W tym czasie miał zeznawać jako świadek w innej sprawie dotyczącej morderstwa – ale odmówił składania zeznań, toteż został skazany na pięć dni aresztu za obrazę sądu. Kiedy pięć dni minęło, na skutek połączenia błędów urzędniczych i problemów wynikłych z pracy komputerów Wright dostał dokumenty uprawniające go do opuszczenia więzienia – i strażnicy odprowadzili go do wyjścia. Był zaskoczony, ale nie protestował. Po tygodniu poszukiwań prowadzonych w całych Stanach Zjednoczonych agenci FBI dopadli go w Boulder City, w stanie Nevada.

Wygląda na to, że wiele równoległych wyroków – zwłaszcza jeśli wydają je władze różnych krajów – także może stwarzać dla komputerów poważny problem. Niejaki Ilija B. był członkiem niesławnego gangu Różowych Panter, który zorganizował ponad 300 kradzieży biżuterii w 35 krajach, kradnąc klejnoty o łącznej wartości ponad 330 milionów euro. Ilija został aresztowany w Niemczech, gdzie skazano go na sześć lat więzienia. Po odsiedzeniu połowy kary okazało się, że w Austrii jest on poszukiwany w związku z procesem o morderstwo. Został zatem przewieziony do Austrii, gdzie skazano go na dodatkowe sześć lat – ale komputery źle obliczyły datę końca wyroku, nie biorąc pod uwagę pozostałej części kary odbywanej w Niemczech. W rezultacie Ilija wyszedł z więzienia o trzy lata za wcześnie – w 2014 roku. Ponieważ sprawa Różowych Panter była głośna, władze szybko się zorientowały w popełnionej pomyłce, ale było już za późno: Ilija zniknął.

Tego typu problemy pojawiają się w systemie zarządzania sprawami dlatego, że małe próby testowe rzadko odzwierciedlają złożoność świata rzeczywistego – zwłaszcza w długich okresach. Kiedy większości ludzi w danej kategorii jest przyporządkowana jedna pozycja – na przykład jeden wyrok skazujący – łatwo jest przyjąć błędne założenie, że w każdej sprawie będziemy mieć do czynienia z jedną i tylko jedną taką pozycją. Dlatego sytuacja, w której mamy do czynienia z kilkoma wydanymi równolegle wyrokami sądowymi, bywa traktowana w niewłaściwy sposób – a brak wyroków skazujących sprawia, że komputery stają się zbyt ufne.

Pozytywna strona tego zjawiska jest taka, że błędy komputerowe nie zawsze stają po stronie przestępców. W 2008 roku komputery w więzieniu w Sadbury, w Wielkiej Brytanii, podniosły alarm, informując o ucieczce niejakiego Michaela Johna Glovera. Wszczęto pościg, który okazał się bezskuteczny – ale wkrótce strażnicy więzienni znaleźli Glovera w jego własnej celi, w której przebywał przez cały czas. Więzienie musiało przeprosić za fałszywy alarm.

Błędne założenia dotyczące tego, co jest, a co nie jest możliwe, okazują się jeszcze większym problemem, jeśli użytkownicy mogą samodzielnie wprowadzać powiązane informacje. O tym właśnie ładnie opowie nam następna historia.Amazon – internetowy „sklep ze wszystkim” – znany jest z eksperymentów biznesowych i stałej orientacji na klienta. Jeff Bezos, człowiek stojący za ogromnym sukcesem Amazona, wyjaśniał podstawową strategię firmy w wywiadzie dla „Washington Post” w 2013 roku: „W Amazonie mamy trzy główne idee, którym jesteśmy wierni od 18 lat i które zapewniły nam sukces – mówił. – Stawiaj klienta na pierwszym miejscu. Bądź kreatywny. Bądź cierpliwy”.

Bycie kreatywnym i wynajdywanie nowych rozwiązań prowadzi do wielu eksperymentów, z których część okazuje się nietrafiona i zostaje anulowana – tak jak telefon Fire Phone. Klienci nie uznali go za szczególnie interesującą propozycję, choć Amazon był bardzo cierpliwy. Skądinąd wiele innych eksperymentów doprowadziło do serii wspaniałych odkryć, takich jak wyszukiwanie oparte na aktywności klienta, które przyniosło firmie miliony dolarów zysku. A jednak, choć orientacja na klienta niezmiennie pozostaje pierwszym punktem strategii Amazona, firma podjęła decyzję o usunięciu jednej funkcjonalności, którą jej klienci uznawali za niezwykle użyteczną: możliwości zamówienia –1 książki.

W wywiadzie przeprowadzonym przez Richarda Brandta, autora książki „Jednym kliknięciem”, Bezos mówi między innymi: „Odkryliśmy, że nasi klienci mogą zamówić ujemną liczbę książek! W takich sytuacjach ich wartość byłaby zaksięgowana na karcie kredytowej klienta, a my, jak sądzę, powinniśmy czekać, aż klient wyśle nam książki…”.

W książce „Amazon Hacks” (dosł. tricki na Amazonie) odkrycie tej funkcji przypisuje się niejakiemu Jonathanowi Leblangowi, jednemu z pierwszych klientów firmy, który w 1999 roku dołączył do zespołu sklepu internetowego jako programista – i do dziś tam pracuje.

Nie da się ukryć, że była to funkcja bardzo skoncentrowana na kliencie. To także doskonały przykład tego, że jakości oprogramowania nie można mierzyć w prosty sposób: dla Amazona ta opcja była zdecydowanie niekorzystna. Jednak z punktu widzenia użytkownika sklepu internetowego ujemna liczba książek miała zdecydowanie dodatnią wartość…

Oczywiście, jeśli zaufamy użytkownikom na tyle, że pozwolimy im wprowadzać wszystko, co będą chcieli – to zawsze będziemy mieli problemy. Kiedy zaczynałem pracę jako zawodowy programista, w czasie „bańki internetowej”, jednym z moich pierwszych zadań było sprawdzenie, w jaki sposób niektórzy klienci uzyskiwali ogromne zniżki w pewnym sklepie internetowym. Przy odrobinie wysiłku wraz z kolegą doszliśmy do wniosku, że sklepowy „koszyk” sumował ceny z przeglądarki internetowej, a skrypt uruchamiany po stronie serwera (back-end) ślepo mu wierzył. Osoby z minimalną wiedzą na temat HTML mogły po prostu edytować stronę i ustalać własne ceny każdego produktu.

Choć co miesiąc ktoś wrzuca na YouTube nowy film z instrukcją, jak zastosować podobny trick w mniejszych sklepach internetowych (wystarczy wpisać w wyszukiwarkę „tamper data shopping”), to handel internetowy jako branża nauczył się już, że należy sprawdzać dane wprowadzane przez użytkowników. A jednak problemy z ujemną ilością nadal się zdarzają.

W 2016 roku na przykład taki problem dotknął pogram instalacyjny usługi Red Hat Cloud – wpisanie ujemnej liczby subskrypcji powodowało aktywowanie wszystkich możliwych subskrypcji. Co więcej – nie chodzi tylko o „koszyki” sklepów internetowych. Popularna platforma do konteneryzacji Kubernetes (k8s) pozwalała użytkownikom na przydzielanie ujemnej ilości pamięci lub mocy obliczeniowej, co powodowało umieszczenie innych kontenerów na hostach, na których nie mogły się zmieścić.

Powód, dla którego takie problemy wciąż się zdarzają, jest prosty: ludzie myślą w kategoriach wartości konceptualnych, takich jak ilość, podczas gdy komputery widzą tylko liczby. Niektóre koncepcje mogą nie mieć większego sensu w prawdziwym życiu – na przykład właśnie ujemna liczba czegoś – więc łatwo nam je przeoczyć. Komputer jednak z radością przełoży je na język liczb.

W systemach zarządzających zamówieniami problem jest jeszcze trudniejszy, bo tu ujemna liczba czasami może mieć sens. Wystarczy pomyśleć o ujemnej liczbie stanu magazynowego jakiegoś przedmiotu, która jest skutkiem sprzedaży zbyt dużej ilości egzemplarzy. Nie chodzi tu przecież o błąd w programie – a może to wręcz oznaczać, że interesy idą lepiej, niż oczekiwano! Zwykle lepiej jest pozwolić, aby stan magazynowy był na lekkim minusie – i szybko zamówić dostawę – niż odmówić klientowi sprzedaży.

Jeśli jednak taka koncepcja ma sens w jednej części dużego systemu, ale jest bez znaczenia w innej, sytuacje graniczne często skutkują błędnymi założeniami i problemami z oprogramowaniem. Pracownicy działu obsługi klienta mogą na przykład próbować wpisywać ujemne zamówienia, żeby w ten sposób zaznaczyć zwroty od klientów. To może skutkować naprawdę fascynującymi konwersacjami między programistami a użytkownikami na temat tego, co jest błędem, a co funkcjonalnością danego systemu – jak komentarz na stronie wsparcia programu IBM Maximo Asset Management: „To nie jest błąd, bo chodzi o ujemne wpływy, a nie o zysk”.

Ujemne wartości to świetny sposób na rozgrywanie poszczególnych części systemu przeciwko sobie, ponieważ użytkownicy często przyjmują na ich temat różne założenia, zwłaszcza jeśli praca jest zorganizowana w taki sposób, że poszczególne jej kroki można odwracać. Na przykład w programie QuickBooks Point of Sale firmy Intuit był kiedyś błąd, który blokował zamówienia, bo jedna część procesu obsługiwała wartości ujemne, a inna po prostu je ignorowała. Użytkownicy mogli wprowadzać przedmioty do formularza zamówienia, potem wycofywać je (np. po to, aby poprawić jakiś błąd) i wprowadzać ponownie – i okazywało się, że zamówienie kończyło się wyświetleniem błędu. Procedura wycofywania próbowała usuwać przedmioty z zamówienia przez dodawanie ich ujemnej liczby, ale system wprowadzania nie akceptował ilości ujemnych, więc to polecenie było ignorowane…

Zaufanie, że użytkownicy będą wprowadzać poprawne dane, stwarzało tak wiele problemów, że większość współczesnych programistów odwala kawał dobrej roboty, potwierdzając i sprawdzając dane wejściowe, aby zapobiegać głupim problemom. Ale nasza branża musi się jeszcze nauczyć, żeby podobnie nie ufać samym komputerom – i o tym traktuje kolejna historia.