Y2K – heca czy historia? Wspomnienia świadka

© NewQuality
Y2K – heca czy historia? Wspomnienia świadka1
Sporo już mówiło się na ten temat: miał się zawalić świat, zdarzyło się jakby niewiele.
Zmowa informatyków, histeria mediów? Moim zdaniem, po prostu konsekwencja
dotychczasowego bałaganu. Nie wiedząc, co się może zdarzyć, spodziewamy się
najgorszego. Gdzie brakuje faktów, wyrastają mity.
Jeszcze kilka lat temu – w 1997 roku - na konferencji „Quality Week” w San Francisco,
Boris Beizer, znany na świecie guru od testowania systemów komputerowych i
oprogramowania, powiedział: „Zaczyna się jakiś ruch wśród przyczep campingowych
na Florydzie i w południowej Kaliforni. Obudzone dinozaury wychodzą na żer – i są
głodne!” Miał na myśli przedstawicieli posiwiałego pokolenia znającego jeszcze
COBOL i systemy operacyjne dużych IBM-ów. Nagle te przestarzałe umiejętności stały
się poszukiwane. Potrzeba było ludzi, którzy byli w stanie przegryźć się przez tajniki
20-letnich i marnie (lub wcale) udokumentowanych programów, żeby stwierdzić, czy i
które były narażone na błąd roku dwutysięcznego.
Wielu teraz wygłasza swoje lepiej lub gorzej uzasadnione opinie, ale tak naprawdę –
jak zwykle kiedy chodzi o ocenę skuteczności metod zapewnienia jakości – brak jest
danych, żeby móc dać odpowiedź ogólną. Nikt nie potrafi z pewnością ocenić, co by
się stało, gdyby nie zrobiono nic. Ile pluskiew milenijnych naprawdę usunięto? Jak
były niebezpieczne? Nie wiemy i wiedzieć do końca nie będziemy. Przedsiębiorstwa
nie kwapią się publikować intymnych szczegółów na temat niedostatków swoich
systemów jakosci, a jeśli nawet, to są to wyrwane z kontekstu szczegóły, podczas gdy
potrzebny jest statystycznie istotny obraz całości. Tego zaś nie uzyskamy nigdy, więc
pozostaniemy skazani na domysły i przypadkowe, oderwane od siebie anegdoty.
Pracownicy wielu firm byli do Sylwestra dobrze przygotowani. Kryzysowe sztaby
czuwały przez całą noc, wieksza grupa musiała być dostępna pod telefonem. Już na
kilka dni wcześniej zakazano korzystania z wielu programów, wprowadzania
jakichkolwiek zmian. Niektórzy teraz są jakby rozczarowani – tyle przygotowań i nic!
No właśnie – może gdyby zawsze równie starannie zabezpieczać programy, systemy i
organizacje, też nudny spokój stałby się udziałem naszej branży, w której na codzień
zbyt często przypominamy sobie stare chińskie przekleństwo „obyś żył w ciekawych
czasach”.
1
Artykuł powstał na początku 2000 roku
Strona 1 (3)
© NewQuality
Na pewno zidentyfikowano i usunięto wiele błędów. Na pewno zdarzyli się też
nieprofesjonalni konsultanci, którzy wykorzystali medialną wrzawę wokół problemu
do wyśrubownia swoich honorariów i ceny kontraktów. Tylko że takie zjawiska nie są
akurat specyficzne ani dla informatyki, ani dla roku 2000…
W sumie cała historia powinna jednak przynieść korzyści. Dokonała się chyba
ostateczna rozprawa z dziedzictwm partyznackich, bałaganiarskich praktyk wczesnej
epoki informatyki. Nieczytelny kod źródłowy, brak dokumentacji, niesprecyzowane
wymagania, zła kontrola wersji, zbyt zawiła i nieprzemyślana konstrukcja – okazały
się w końcu o wiele, wiele kosztowniejsze niż cena odrobiny dyscypliny, która
pozwoliłaby tego wszystkiego unikać zawczasu.
Wyszło na jaw, że oprogramowanie ma dłuższe życie niż niegdyś sądzono i że wobec
tego powinno być udokumentowane i przechowywane równie porządnie, co plany i
rysunki domów, statków albo samolotów. Pozorna łatwość, z jaką programista i
konstruktor systemu może przesuwać cegły swojej konstrukcji nawet kiedy calość jest
już gotowa, jest tylko fikcją, jeśli nie ma się dokładnej wiedzy o roli i funkcji każego
kawałka cyfrowej budowli. Nikt nie odważy się zmodyfikować żadnej rutyny, jeśli
konsekwencją może okazać się zapaść całego systemu.
Gigantyczny skok funkcjonalności, jaki ludzkiej cywilizacji przyniosło odkrycie sposobu
tworzenia konstrukcji z elektrycznych sygnałów zamiast z żelaza, drewna i betonu, da
się utrzymać tylko pod warunkiem solidnej kontroli jakości. W przeciwnym razie
budowle zaczną się walić pod ciężarem swojej wciąż rosnącej złożoności. Bez
porządnej dokumentacji – czego przedsiębiorstwa i instytucje całego świata boleśnie
zaznały na własnej skórze – koszt każdej przeróbki po upływie kilku lat staje się
równie wielki, jak cena przebudowy parteru, kiedy dach domu jest już gotowy…
Ta wiedza, wcześniej dość egzotyczna, stała się – dzięki problemowi roku 2000 –
dostępna każdemu księgowemu, dyrektorowi i innym trzymającym dłoń na kasie
managerom, dawniej jakże skłonnym do krótkowzrocznych oszczędności w działach
informatyki swoich przedsiębiorstw. Problem roku 2000 mieli przecież wszyscy,
niezależnie od tego, czy programy wymagały naprawy czy nie: kosztowne okazało się
po prostu zorientowanie się w całym tym informatycznym bałaganie. Może dzięki
temu przybliżył się dzień, kiedy solidna dokumentacja i żmudne testowanie staną się
równie oczywiste dla oprogramowania, jak są już dziś dla każdego wieżowca,
samolotu albo mostu!
„Im gorzej, tym lepiej” – to budzące moralne wątpliwości hasło niejednej radykalnej
opozycji było w tym wypadku chyba uzasadnione. Wielkie sumy, które trzeba było
przeznaczyć na rekognoskowanie organizacyjnych lochów i konstrukcyjnych dżungli,
przyczynią się - miejmy nadzieję - do tego, że żyjąc w świecie coraz bardziej
Strona 2 (3)
© NewQuality
skomputeryzowanym, nie będziemy jednocześnie musieli żyć w świecie coraz bardziej
chaotycznym i niepewnym!
Wiele firm konsultingowych w Szwecji liczyło się z trudnościami, kiedy pod koniec
roku 1999 miało jakoby nastąpić nagłe przesycenie rynku specjalistami od testownaia
i od jakości, którym pokończą się lukratywne kontrakty Y2K. Nic podobnego nie
nastąpiło. Dinozaury zdołały się nasycic, a świat informatyki niepostrzeżenie wspiął
się na wyższą gałąź ewolucji?
Czas pokaże, na ile trafna jest ta diagnoza.
Strona 3 (3)