Śmierć systemu

Jesteśmy (my, programiści) zafascynowani procesem, w którym systemy informatyczne się rodzą. Organizacja pracy, metody, narzędzia, wzorce, języki, plany. Byle dotrzeć do magicznego 1.0 (choćby i beta). Byle dostarczyć. Byle uruchomić.

Coraz lepiej uświadamiamy też sobie, że to nie koniec, że po rozruchu aplikacje żyją dalej. Uczymy się, jak je tworzyć, by ewolucja była możliwa, by 1.0 było fundamentem a nie ostatnim krokiem. Rozważamy różne modele rozwojowe.

O śmierci systemów mówimy najmniej. I chyba nawet nie dlatego, że sprawa to przykra. Rzadko kiedy przy niej jesteśmy.

To prawda - bywają nagłe wypadki. Projekty zabite jeszcze przed uruchomieniem albo tak niedoskonałe, że unicestwione wkrótce po nim. O nich mówimy - ale zastanawiamy się głównie nad procesem rozwojowym. Czemu źle rosło, co trzeba było robić inaczej, jak to w przyszłości poprawić.

Ale systemy udane też umierają.

Choroba

Patche, patche do patchy, obejścia, skrótowce, uwiązanie do nieudanych API albo niefortunnych przyzwyczajeń użytkowników, ślady pośpiesznych kompromisów, nieudokumentowane a niezbędne zachowania, mieszaniny pomysłów wielu osób, coraz bardziej niepełne testy.

Klarowny kształt rozmywa się i rozpada. Coraz więcej miejsc, w których strach cokolwiek zmienić, coraz więcej elementów żyjących własnym niekontrolowanym życiem, coraz wszystko sztywniejsze, oporniejsze.

Kojarzy mi się to z chorobą.

Jeśli trwa to zbyt długo, jeśli zajdzie za daleko - następuje koniec. Zmiany są już za trudne, za drogie, zbyt bolesne.

Zasłyszana z wiarygodnych ust anegdota: jeden z angielskich banków nie wprowadza już żadnych zmian w swojej infrastrukturze informatycznej. Nie tylko nie rozwija używanych aplikacji ale nawet nie aktualizuje oprogramowania systemowego i nie modernizuje hardware. Boją się cokolwiek ruszyć, bo nie umieją ocenić konsekwencji.

Śmiałem się. A potem przypomniałem sobie nigdy nie udokumentowane i teoretycznie od ośmiu lat nieużywane API, ciągle krytycznie mi potrzebne przy testach.

Starość

Z kolei przestarzałość jest częściej pretekstem niż prawdziwą przyczyną. Argumentu o języku programowania sprzed piętnastu lat łatwo użyć i łatwo jest go zrozumieć. Ale tak naprawdę często kryje się za nim potrzeba przepisania od nowa zbyt już trudnej w utrzymaniu aplikacji.

Więcej o nowościach będę chciał napisać przy innej okazji (lekko zacząłem w bajce o programującym durniu). Może tylko jedna uwaga: w tym samym czasie, w którym jedni narzekają na przestarzałość C++, Javy, Perla czy SQL-owych baz danych, inni wdrażają nowoczesne systemy pisane właśnie w tych technologiach. Albo z użyciem COBOLu, CICSa oraz bazy na mainframe.

Jaki jest tu prawdziwy problem? Rekrutacja. Nowe, modne technologie są powszechnie znane, a kto ich nie zna - chętnie się nauczy. Im narzędzie starsze i mniej efektowne, tym trudniej odświeżać i poszerzać zespół.

Tak czy siak: starsze platformy lub narzędzia same z siebie jeszcze nie muszą oznaczać śmierci systemu. O ile trwa jego rozwój funkcjonalny.

Brak duszy

Coraz bardziej jestem przekonany, że aby system żył, musi mieć duszę. Musi stać za nim człowiek. Konkretny człowiek.

Czasem jeden lider, czasem jakaś stanowiąca trzon zespołu grupa. W obu wypadkach - ktoś, kto ma jasną wizję danej aplikacji, stale pozostaje zaangażowany w jej rozwój, jest zmotywowany, ma też niezbędne środki i autorytet by autentycznie nadzorować prowadzone prace.

Ta rola nie musi być dożywotnia, pochodnię można przekazać następcy (bywa to nawet korzystne jeśli pierwotny lider zaczyna się czuć wypalony czy po prostu łaknie nowych wyzwań).

Ale nie można jej puszczać obiegiem.

Szczerze, serdecznie nienawidzę programistoroboczogodzinnego trybu pracy, w którym doskakuje się do coraz to innej aplikacji, wstawia taką czy inną łatę, po czym porzuca temat i biegnie do innych spraw. By przy kolejnej wizycie znaleźć niespójne ślady działalności paru innych osób.

To coś nie jest moje. Nie jest Twoje. Nie jest jego. Jest niczyje. Nie ma duszy, więc będzie się rozwijać czysto reaktywnie, chaotycznie, na chybcika. Rękami coraz bardziej niechętnych ofiar łapanek, realizujących absolutne minimum i pozbywających się gorącego kartofla przy pierwszej sposobności.

4+6+7+9+5+2+1+6

Widmo MS Project ciągle krąży. Nawet gdy narzędzie to nie jest używane, pozostawia w głowach myślenie rolami a nie osobami oraz sprowadzanie zadań do prostych zależności i szacowanych czasów realizacji.

I dodawanie do 40.

Ziutek Nowak, trzeci tydzień października. 19 godzin na kilka drobnych poprawek w projekcie A, 14 na testowanie projektu B, 7 zostaje, więc niech zrobi jakieś zgłoszenie dotyczące C. Tak będzie efektywnie.

W rzeczywistości 8 godzin pójdzie na przełączanie kontekstu, od technicznej reanimacji środowiska developerskiego po przypominanie sobie, o co właściwie chodzi w projekcie. Drugie 8 zapłacą inne osoby - wypytywane, muszące udzielać pomocy, pilnujące. Zaś skoro przy samej pracy o motywację będzie trudno, końcowy efekt będzie gorszy, niż gdyby Ziutkowi po prostu dano popracować przy A.

No - ale nic się nie może zmarnować.

Johanna Rothmann napisała (w Manage It): w mojej pracy wielozadaniowość jest najważniejszą przyczyną opóźnień w projektach, projektów nie dostarczających właściwych produktów czy dostarczających produktów niewystarczającej jakości (...) Przerzucanie między zadaniami może kosztować od 20% do 90% czasu.

Później radzi, by jeśli już jest to absolutnie niezbędne, ograniczyć przełączanie kontekstu do weekendów, dając przynajmniej pełny tydzień na pracę nad powiązanymi zadaniami w jednym projekcie.

Parę artykułów dyskutujących problem wielozadaniowości z bardziej psychologicznego punktu widzenia można znaleźć tutaj.

Paul Graham (w artykule o którym już niedawno wspominałem) ciekawie komentuje samą sprawę rozliczania pracy w oparciu o godziny - uznając to za wyraz bezradności firm w ocenianiu działań pracowników. I do problemów indywidualnych dorzuca aspekt społeczny. Ludzie zmuszeni do wykazania się czasem spędzonym przy projektach nie tylko sami będą zdemotywowani ale też będą przeszkadzać tym, którzy naprawdę pracują (choćby masą niepotrzebnych spotkań i dyskusji).

Drugie życie

Aplikacja zbliża się do śmierci technicznej? Trudno. Można przepisać od nowa.

To prawda.

Ale to kosztuje czas. Dużo czasu. Czasu, w którym nad starym wisi już miecz, a nowego jeszcze nie ma. Wysiłku, który nie dostarczy użytkownikom niczego nowego, co najwyżej trochę irytacji.

Do tego ta sama choroba, która zabiła stary system, czyni trudnym ustalenie dokładnej funkcjonalności jego następcy. Po co właściwie jest wywoływana ta usługa? Czy ktokolwiek wie, jak działa ten ekran?

Pośpiech i niewiedza mogą nawet sprowokować do skopiowania starego bałaganu.

Boli też wdrożenie. Zastępowanie działającego ważnego systemu innym jest dużo dużo trudniejsze niż pierwsza instalacja czy upgrade do nowej wersji. Migracja danych. Ponowne szkolenie użytkowników i administratorów. Przebudowa narzędzi administracyjnych (monitoring, raportowanie błędów, procedury instalacyjne, ...). Strojenie wydajności. A wszystko to przy konieczności utrzymania ciągłej pracy.

Nietrudno o przykłady spektakularnych niepowodzeń.

Swego czasu głośny był artykuł Joela Spolskiego, z bardzo krytyczną oceną przepisywania aplikacji od nowa.

Pozornie autor wyszedł na durnia. Przeglądarka Mozilla w końcu powstała, okazała się lepsza od starego Netscape, dziś jako Firefox święci triumfy.

Trzeba jednak pamiętać, że ogromny udział miał w tym Microsoft, który na pięć lat wstrzymał rozwój swojej przeglądarki (mając swoją rozsądną motywację - walcząc o zachowanie przewagi desktopu nad WWW). Mało prawdopodobne, by gdziekolwiek powtórzyły się aż tak korzystne warunki.

No i nie zapominajmy, że firma Netscape tego sukcesu nie dożyła.