Zmienność - istota systemu informatycznego

Krótka historia jednego błędu

Puśćmy na chwilę wodze fantazji. Jakiś informatyk siedzi sobie spokojnie w pracy, obmyślając właśnie sposób na sortowanie tablicy, której tylko część jest w pamięci operacyjnej, a reszta na dysku, a tu nagle dzwoni telefon. Wyraźnie rozzłoszczony głos najpierw wyzywa go od najgorszych, a potem informuje, o co mu chodzi. Otóż klientem jest biuro turystyczne, które kupiło od jego firmy aplikację do zarządzania wycieczkami. Okazuje się, że od pewnego czasu nazwiska niektórych uczestników wycieczek nie widnieją na listach rezerwacji lotniczych, za to uczestnicy innych wyjazdów mają rezerwacje podwójne. Informatyk prosi o podanie numeru klienta z podwójną rezerwacją i słyszy "osiemnaście", co wydaje mu się liczbą za małą. Chwilę jeszcze rozmawia, po czym przypomina sobie, że numer seryjny uczestnika wycieczki był zapisany w formie liczby szesnastobitowej bez znaku i pewnie po liczbie 65 535 nastąpiła cyfra 0.

Chwilę jeszcze uspokaja rozeźlonego klienta, prosi, aby sprzedaż wycieczek była dokonywana na razie bez użycia systemu informatycznego, i informuje rozmówcę, że otrzyma uaktualnienie jutro do południa. W odpowiedzi słyszy, że uaktualniona wersja ma być dzisiaj, bo jest środek sezonu, a jutro można co najwyżej zgłosić się do kancelarii radcowskiej w celu znalezienia dobrego pełnomocnika.

Informatyk rzuca wszystko i:

Zmienia typ atrybutu w klasie z word na long. Nie rozwiązując w ten sposób problemu, tylko odsuwa go w czasie, ale chwilowo to wystarczy (0,25 godz.).

Kompiluje źródła na najszybszej maszynie, odbierając ją koledze, który właśnie robił coś mniej pilnego (0,5 godz.).

W trakcie kompilacji przegląda dokumentację w bazie danych i wypisuje wszystkie pola, których szerokość należy zmienić.

Krytyczną procedurę przechodzi sekwencyjnie (0,5 godz.).

Pisze skrypt modyfikujący schemat bazy danych (0,5 godz.).

Uruchamia automatyczne testy (0,5 godz.).

Generuje wersję instalacyjną programu (0,5 godz.) i instaluje ją na jedynym wolnym komputerze w sekretariacie, czemu bezsilnie przygląda się pani Jola, której przerwano pisanie korespondencji (0,5 godz.).

Aplikacja szczęśliwie działa, łapie więc w korytarzu wdrożeniowca i każe mu się wieźć do klienta na drugi koniec miasta (1 godz.).

Na miejscu najpierw pokornie wysłuchuje wszystkiego, co mają do powiedzenia, a potem instaluje nowe oprogramowanie przy pomocy lokalnego informatyka. Ponieważ wszyscy patrzą mu na ręce, zajmuje to dwa razy więcej czasu niż zwykle (2 godz.).

Zostaje na miejscu do czasu aż klient wprowadzi kilka próbnych wycieczek i upewni się, że rezerwacje działają prawidłowo (1 godz.).

Wstąpiwszy na zasłużoną pizzę, po powrocie do pracy uaktualnia dokumentację techniczną do aplikacji i bazy danych. Nie zapomina odinstalować niepotrzebnej już aplikacji z komputera pani Joli (0,5 godz.).

Uaktualnia automatyczne testy tak, aby w przyszłości w tej i innych miejscach wykrywały podobne sytuacje (1,25 godz.).

Przy najbliższym spotkaniu z szefem cierpliwie odpowiada na pytania, na ilu bitach przechowywane są kwoty, gdzie stosowane są zmienne ze znakiem i jakie testy zostały wykonane zanim uznano aplikację za zakończoną. Na imieniny koledzy kupują mojemu informatykowi kolorowy album Encyklopedia siedmiolatka: komputer. Udaje, że go to bawi.

Policzmy teraz: na naprawienie błędu poświęcono 9 godzin informatyka, 3 - klienta, 4 - wdrożeniowca, 3 - lokalnego informatyka i godzinę pani Joli. Przy zryczałtowanej stawce 20 zł za godzinę daje to stratę 420 zł. Do tego nerwy, obcięta premia, opóźnienie w bieżących pracach i zepsuta marka u klienta. Aha, i nie zapominajmy o koszcie pizzy! A wszystko dlatego że przy projektowaniu klasy ktoś nie pomyślał przez 30 s nad zakresem typu atrybutu.

Nad każdą decyzją zastanów się 30 sekund

To oczywiście był scenariusz optymistyczny. Scenariusz pesymistyczny brzmi tak: w firmie wszystko działało, ale klient ma inną sieć. Guru, który potrafił skonfigurować nową instalację w tej właśnie sieci, jest aktualnie na urlopie. Pomimo kilkugodzinnych starań, nie udaje się zainstalować poprawionej aplikacji, a stara już nie działa, bo uaktualniono schemat bazy danych. Po kilku dniach firma odbiera fakturę z niesamowitą liczbą zer, a chwilę później winowajca otrzymuje wypowiedzenie. W czasopiśmie Polskiej Izby Turystyki ukazuje się kwiecisty opis zaistniałej sytuacji, co sprawia, że firma musi się wycofać z branży turystycznej, a informatyk szukać pracy w innym mieście.

<hr size=1 noshade>Tekst jest fragmentem rozdziału Proces i produkt książki Jakuba Chabika pt. Praktyka skutecznego programowania, która ukaże się we wrześniu br. nakładem poznańskiego wydawnictwa Nakom.