Gdzieś na początku lat siedemdziesiątych popularna była w Polsce historyjka obrazkowa, pochodząca z nie istniejącego już miesięcznika Datamation. Przedstawiała ona trafnie realia kolejnych etapów realizacji projektu informatycznego. Rozpoczynały ją wygórowane wymogi władz firmy, a kończyła się powstałym w ich wyniku systemem informatycznym, który jakoś działał tylko dzięki kompromisom i uproszczeniom.

W tym samym czasie spotkałem się pierwszy raz z metodą tworzenia i wdrażania systemu informatycznego, którą nazwałem "ucieczką do przodu".

Przypominało to, pod pewnymi względami, hazard, w którym już ta następna gra będzie wygrana, a wszystkie poprzednie niepowodzenia były tylko koniecznym do niej wstępem.

Analogia informatyczna polega tu na wyborze i zakupie systemu, który wydaje się spełniać pokładane w nim nadzieje, ale przy bliższym poznaniu okazuje się dość od nich odległy. Ponieważ rozliczne względy uniemożliwiają wycofanie się z takiego przedsięwzięcia, jedynym wyjściem z trudnej sytuacji wydaje się wspomniana ucieczka do przodu, czyli wzbogacenie posiadanego już, a wielce niedoskonałego rozwiązania w coś, co usunie tę niemiłą dolegliwość. Antidotum tym jest albo dodatkowa opcja do systemu, albo dopisane we własnym zakresie moduły, a czasem nawet nowy, uzupełniający system. Niezależnie od tego, który ze sposobów wybrano, jedno jest pewne: nieprzewidziane koszty są nieuniknione.

Działanie takie zazwyczaj nie rozwiązuje niczego, a pośpiech i nerwowość, wynikające z próby zamaskowania dotychczasowych niepowodzeń, jeszcze pogarszają sytuację.

Ponieważ w którymś momencie nie ma już dokąd uciekać, a cofać się nie można i nie wypada, zaczyna się sprzedaż jako sukcesu tego, co dało się doprowadzić do jako takiego działania. Towarzyszy temu bagatelizowanie części, które się nie powiodło, oraz neutralizowanie i izolowanie ewentualnych krytyków.

Istotne zmiany i poprawki do takiego systemu (o ile w ogóle daje się go dłużej tolerować) trwają latami i nigdy się nie kończą. W przyspieszonym tempie rośnie ilość tzw. martwego kodu, czyli tej części systemu, która choć istnieje, nigdy nie jest wykonywana. Zajmuje ona jednak miejsce na dyskach i nośnikach archiwalnych, a także wydłuża czas archiwowania i odtwarzania zawartości dysków. Dłużej trwają przez to kompilacje, do których potrzeba mocniejszych komputerów, a kolejne zwiększenia pamięci operacyjnej są pożerane w zawrotnym tempie. Badania z tego zakresu przeprowadzone przy okazji rozwiązywania problemu roku 2000 wykazały, że w niektórych systemach, po latach, martwy kod stanowi blisko połowę całości. Tu jednak objętość tego kodu jest znaczna już na początku stosowania systemu. A wszystko to kosztuje...

Można by sądzić, że problemy takie należą do dawno minionej przeszłości. Okazuje się jednak, że wcale tak nie jest, a współczesnych przykładów nie brak. Nie dalej jak w ubiegłym roku przerwano realizację systemu wypłat rent i zasiłków, wykonywanego dla poczty brytyjskiej. Straty są tam dwóch rodzajów: wydano ponad miliard funtów brytyjskich i bezpowrotnie, na rzecz banków, stracono możliwość obsługi dochodowych transakcji finansowych, jakimi w istocie są takie wypłaty. Oficjalnie jednak podkreśla się korzyści wyniesione z tego przez klientów poczty, którzy mogą się teraz posługiwać specjalnymi kartami, na wzór kart płatniczych. Szkopuł jednak w tym, że karty te, wraz z całym sztafażem sprzętowo-programowym, wprowadzono w celu obsługi wypłat, których się nie obsługuje.

A w ogóle - czy koniecznie musimy sięgać aż po zamorskie przykłady tego rodzaju?