Liczby mają moc magiczną. Ktoś powiedział, że liczby rządzą światem. Numerologia jest poważną gałęzią wiedzy (specjalnie nie napisałem 'nauki'). Na każdym kroku spotykamy liczby mające specjalny wpływ na nasze życie: 3, 7, 10, 13, 44, 666, 1996, 2000. Za kilka lat przyjdzie w chwale liczba najbardziej magiczna i od dawna oczekiwana z niepokojem, aby na zawsze odmienić nasz świat. Co się wtedy stanie z nami? Co się stanie z naszymi systemami komputerowymi??

Gdy data zmieni się wraz z nadejściem roku 2000, posieje spustoszenie w systemach komputerowych, zostawiając w pyle wraki formuł obliczeniowych. Jak na razie tylko nieliczne firmy próbują zmierzyć się z problemem. Jeśli zaczniesz działać już teraz... być może zdążysz.

Jestem idealistą. To dla mnie utrapienie, ale również stanowi o mojej sile. Znaczy, że lubię dokładność - nie w sensie "tak dokładnie, jak to jest możliwe", ale "śmiertelnie dokładnie". Nie lubię niejasności, nie lubię też niepotrzebnego ryzyka - zwłaszcza tego, które niesie ze sobą nieznane i w głównej mierze negatywne konsekwencje.

Czy to dziwne, że od jakiegoś czasu mam obsesję na temat problemu ze zmianą daty w roku 2000?

Kto się już boi, a kto jeszcze nie?

Większość aplikacji przechowuje dane na temat roku w formacie dwucyfrowym. Nasze systemy zakładają, że te dwie cyfry (np. 34) poprzedzone są przez 19 (co daje 1934). Kiedy wartość "rok" przybierze postać 00 w 2000 r., programy w większości uznają, że jest to 1900, powodując błędy w działaniu systemów i nieadekwatne raporty.

Bazując na rozmowach przeprowadzonych na świecie w setkach firm, z wieloma konsultantami i producentami oprogramowania, doszedłem do wniosku, że zaledwie 20% przedsiębiorstw zaczęło zajmować się problemem roku 2000. Do tego większość z owej liczby przewidujących znajduje się jak na razie dopiero w początkowej fazie planowania.

Z programistycznego punktu widzenia sprawa jest trywialna.

Wystarczy rozszerzyć pole daty o dwa znaki, albo dodać pole logiczne będące wskaźnikiem stulecia. Dobrze jest też zauważyć, że rok 2000 jest rokiem przestępnym. Jeśli nie weźmie się tego pod uwagę, aplikacje nie będą wiedziały, jaki dzień tygodnia jest po dniu 28 lutego 2000 r.

Skala zagrożenia

Wcale nie do rzadkości należą firmy, które muszą przeszukać ponad 50 mln linii kodu, aby znaleźć odwołania do pól daty;co gorsza, coraz mniej dni zostaje do spotkania z terminem, który - jak żaden inny dotąd - jest raczej nieprzekraczalny. Jeśli przyjmiemy, że do sprawdzenia, naprawienia, przetestowania i zaimplementowania zmiany potrzeba dokładnie jednej sekundy w przeliczeniu na jedną linię kodu źródłowego, jeśli pracujemy 8 godz. dziennie, 5 dni w tygodniu i 50 tygodni w roku - otrzymamy coś około siedmiu lat pracy. (Tak, wiem, że jest to absurdalny sposób na mierzenie skali projektu, ale od czegoś trzeba zacząć.)

Co więc zrobić najpierw? Od jakich zewnętrznych aplikacji jest uzależniony wasz system? Kiedy moduły współpracujące będą gotowe do komunikowania się z waszym zmodyfikowanym oprogramowaniem? Jak zareagują firmy, które są producentami waszych pakietów? Niewątpliwie jest to największe wyzwanie projektowe, w jakie byliście kiedykolwiek zaangażowani.

Wymagać będzie ono najściślejszych metod kontroli, gdyż ostatecznego terminu ukończenia pracy nie da się niestety przesunąć.

Oblicza obsesji

Moja obsesja przyjmowała już różne nazwy: była "Cyfrowa Kasandra", "Lament Millenijny", jak również "Wieszcz Zagłady". Podobno niektórzy strzelają do posłańca, który przywiózł złe wieści... Takie jest życie.

Ale problem jest prawdziwy. Krótko i jasno ujęła go Kathy Benson, dyrektor ds. projektów w IBM: "Jest nakazem chwili, aby klienci poprawili CAŁE swoje oprogramowanie - systemy operacyjne i aplikacje, lub wymienili na najnowsze dostępne wersje. Inaczej będą mieli kłopoty po 1 stycznia 2000 roku".

Problem występuje na wszystkich platformach sprzętowych - nie tylko na dużych systemach. Spróbujcie wykonać test na swoim PC: ustawcie datę na 31.12.1999, zaś godzinę na 23:57.

Wyłączcie komputer i odczekajcie pięć minut. Włączcie i sprawdźcie datę. No i jak? Co pokazuje system? Czy przypadkiem nie jest to 4 stycznia 1980?! Zakładam się, że w każdym razie nie będzie to 1 stycznia 2000. (Teraz dopiero strach was obleciał, co? - przyp. tłum.). Oznacza to ni mniej, ni więcej, że w nowym stuleciu wasz system będzie bezużyteczny. Wasze śliczne programy napisane w Clipperze i w Excelu będą bezużyteczne. O ile oczywiście ich nie naprawicie, czy też raczej nie wymienicie na poprawnie działające.

Problem na skalę biznesu

Kłopot w większości systemów polega na tym, że nie wiadomo kiedy, jak i czy padną one w 2000 roku. Niestety nie stać nas na to, aby nie wiedzieć. Czy ktoś podejmie ryzyko związane z faktem, że nie będzie można wystawić ani jednej faktury??

Dwie brakujące cyferki mają oddziaływanie dużo szersze, niż li tylko techniczne. Niezależnie od faktu, że u źródeł kryją się jakieś bity i bajty, w rezultacie problem rzutuje na całą działalność waszej firmy. Jeśli jesteś programistą wiesz, że kod może nawalić. Jeśli jesteś analitykiem wiesz, że program padnie. Jeśli jesteś głównym informatykiem wiesz, że aplikacje firmy mogą działać błędnie i wiesz, co to znaczy dla działalności przedsiębiorstwa. To właśnie na Tobie spoczywa moralny obowiązek i główna odpowiedzialność za poinformowanie zarządu o nadciągającym zagrożeniu.

Ryzyko prowadzenia biznesu ma swoje korzenie również w technicznych podwalinach waszej organizacji. Ty zbudowałeś te fundamenty. Rozumiesz, że skomplikowane systemy mogą upaść z powodu brakującego lub wadliwego malutkiego elemenciku.

Przeto wielkim głosem wołamy obaj (autor i tłumacz - przyp. tł.) -informatyku, dyrektorze: CZY JESTEŚCIE PRZYGOTOWANI?????

Tłumaczył Jan Sobolewski