Y2K – heca czy historia? Wspomnienia świadka
Transkrypt
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)