Entropia oprogramowania i koszt utrzymania

Czasy, kiedy można było wdrożyć system i spokojnie zostawić go na kilka lat, już minęły.

Entropia oprogramowania: aplikacja jest „nienaruszona”, ale zmienia się wszystko wokół niej: system operacyjny, przeglądarki, zewnętrzne API i biblioteki. Bez utrzymania dziś działa, za rok są alerty i zepsuta integracja, za dwa lata dziesiątki luk i przepisywanie od zera. Utrzymanie to warunek działania

Dlaczego system, którego nie zmieniamy, przestaje działać?

Bo zmienia się wszystko wokół niego. Dziś Wasza aplikacja mobilna może działać bez zarzutu, platforma e-commerce generować stabilne przychody, a system wewnętrzny obsługiwać procesy. I nagle, rok później: „przestała działać na najnowszym iOS”, „klienci dostają alerty bezpieczeństwa”, „integracja z bankiem się zepsuła”. A przecież nic nie zmieniliście.

To entropia oprogramowania, czyli koszt utrzymania.

Co dokładnie się zmienia?

Wasza aplikacja działa w ciągle zmieniającym się ekosystemie. Systemy operacyjne aktualizują wymogi bezpieczeństwa. Zewnętrzne API wycofują stare wersje. Przeglądarki przestają wspierać używane technologie. Biblioteki publikują krytyczne poprawki.

Rezultat? Aplikacja „nienaruszona” od dwóch lat ma dziś dziesiątki luk bezpieczeństwa i może przestać działać w każdej chwili.

Meir Lehman opisał to już w latach 70. jako prawo ciągłej zmiany: system używany w realnym świecie musi być stale dostosowywany, inaczej z czasem staje się coraz mniej użyteczny. Nie dlatego, że ktoś go zepsuł. Dlatego, że świat poszedł dalej.

Dlaczego odkładamy utrzymanie?

Bo nikt nie chce za nie płacić. W prezentacjach biznesowych mówimy o rozwoju nowych funkcji, nie o tym, ile kosztuje utrzymanie tego, co mamy.

Nikt nie chce słyszeć, że część budżetu IT powinna iść na to, żeby rzeczy po prostu… dalej działały. To brzmi jak marnotrawstwo. Więc odkładamy.

Problem w tym, że odłożone utrzymanie nie znika. Rośnie. Aktualizacja biblioteki o jedną wersję to zwykle godzina pracy. Aktualizacja o pięć wersji naraz to projekt, który trzeba planować, testować i tłumaczyć. A jeśli czeka się do momentu, gdy coś przestanie działać, termin wyznacza już nie zespół, tylko dostawca systemu operacyjnego albo bank. Praktyki, które pomagają utrzymywać kod na bieżąco, opisałem we wpisie o Extreme Programming.

Czym jest utrzymanie, jeśli nie kosztem?

Utrzymanie to warunek działania i możliwość szybszego reagowania na nowe potrzeby.

System, który jest na bieżąco, łatwo zmienić. Nowa funkcja nie wymaga najpierw tygodnia aktualizacji zależności, a poprawka bezpieczeństwa wchodzi w ciągu dnia, a nie po miesiącu negocjacji. Organizacje, które znajdują sobie sposób na sprawne zarządzanie tym tematem, nie muszą przepisywać od zera.

Te, które go nie znajdują, co kilka lat stają przed decyzją o wielkim projekcie „nowej wersji”, która w praktyce jest spłatą długu narosłego przez lata odkładania.

Kto powinien ponosić koszt utrzymania?

To pytanie warto zadać wprost, zanim zrobi to awaria. Jeśli utrzymanie nie ma swojego miejsca w budżecie i w planie pracy zespołu, zostaje zrobione dopiero wtedy, gdy jest najdroższe.

Jak w Waszych organizacjach wygląda dyskusja o kosztach utrzymania systemów IT i kto je ponosi?

Bibliografia

Lehman, M. M. (1980). „Programs, Life Cycles, and Laws of Software Evolution”. Proceedings of the IEEE, 68(9).
Cunningham, W. (1992). „The WyCash Portfolio Management System”. OOPSLA ’92 Experience Report.
Hunt, A., Thomas, D. (1999). The Pragmatic Programmer. Addison-Wesley.
Winters, T., Manshreck, T., Wright, H. (2020). Software Engineering at Google. O’Reilly Media.

💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem

Ten o entropii oprogramowania