Dług technologiczny

Dzisiaj będzie o długu technologicznym, czyli o sprytnie ukrywającym się koszcie projektu. Koszcie, który z czasem potrafi zabić najlepsze projekty a nawet firmy.

„As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.”

Meir „Manny” Lehman 1980

Parafrazując ciągle zmieniający się program zwiększa swoją złożoność o ile nie pochylimy się nad kodem aby ją zmniejszyć. Pisanie programów jest łatwe, wręcz banalnie łatwe, jednak pisanie tak, aby dało się je długo i w miarę tanio utrzymywać jest bardzo trudne. Wynika to z dwóch złożoności. Jedna to złożoność samego problemu, druga to złożoność przypadkowa. Tą przypadkową tworzymy my sami – programiści. Sami komplikujemy soft bardzo często zupełnie niepotrzebnie. Sami idąc na skróty gmatwamy kod tak, że staje się z dnia na dzień coraz droższy w utrzymaniu. To podrażanie utrzymania to właśnie dług technologiczny.

Dług technologiczny, jak każdy dług ma to do siebie, że im dłużej nie spłacany tym więcej będzie kosztować. Każda droga na skróty jest jak zaciągnięcie małej pożyczki, której jeśli nie spłacimy szybko – nie poprawimy kodu za tydzień/miesiąc – może nas zniszczyć samymi odsetkami. Oczywiście nie zniszczy nas od razu. Dług zabija powoli, tak jak rosnące powoli odsetki lub jak tłuszcz odkładający się w żyłach.

Dług technologiczny to nie tylko pójście na skróty podczas kodowania, to również zaniechanie przechodzenia na najnowsze wersje narzędzi programistycznych oraz nie wspieranie najnowszych systemów operacyjnych. Znowu na początku nic takiego się nie dzieje – nawet możemy odczuć zbawienne skutki nieprzechodzenia na nowe wersje w końcu nie marnujemy czasu na zmianę IDE czy dociągnięcie kodu tak, żeby wspierał najnowszy system np. Win8 – jednak z czasem, może się okazać, że jest za późno.

Jak to działa?

Wyobraźmy sobie, że piszemy aplikacje pod .net 1.1 i zamiast przechodzić na kolejne wersje frameworka jak wychodziły cały czas pracujemy z 1.1 Po kilkunastu latach wychodzi Windows X, na którym framework 1.1 Mamy ostatnią szansę, żeby coś z tym zrobić, adaptacja windowsów trochę trwa. Przesypiamy jednak ostatnią szansę (czytaj mamy milion wymówek) i 2 lata później, jak ~50% ludzi korzysta z Windowsa X my dalej nie przeszliśmy na nowszą wersję. Właśnie doszliśmy do sytuacji gdzie odcieliśmy się od połowy potencjalnych klientów. Być może właśnie nasz projekt zaczyna umierać.

Oczywiście można wszystko przepisać ale ile to kosztuje? Można też przejść na nową wersję (W KOŃCU) ale kto pamięta jakie były rozwiązania problemów przy zmianie z strasznie archaicznej na mniej archaiczną?

Wszelkie narzędzia programistyczne, ide, kontrolki, biblioteki, frameworki musimy trzymać w możliwie najnowszej wersji, bo tylko dzięki temu możemy ustrzec się przed powolnym uśmiercaniem projektu.

“Możliwie najnowsza”  czyli kiedy zmienić wersję?

No właśnie, kiedy zmienić wersję? Z doświadczenia widzę, że jak najszybciej bo to właśnie wtedy najłatwiej znaleźć informację jak rozwiązać problemu przy zmianie wersji. Chyba najlepiej przejść z jedną maszyną czy projektem (w zależności czego wersję zmieniamy) aby oszacować możliwe koszty i przetrzeć szlaki a potem ruszamy z resztą. Gdybym miał określić jakieś konkretne ramy czasowe to myślę, że w połowie czasu pomiędzy wydaniem wersji x a wersji x+1 cała organizacja powinna dokonać zmiany.

Źródła długu technologicznego

Wymieniłem dwa źródła długu technologicznego:

  • droga na skróty w programowaniu
  • używanie nieaktualnych wersji

jest ich jednak więcej. Między innymi:

  • droga na skróty w architekturze,
  • brak elastyczności
  • brak testów
  • brak współpracy
  • brak refaktoryzacji
  • wypuszczanie niedokończonych wersji z rzeczami “na później”

Każda z wyżej wymienionych rzeczy (a pewnie i wiele wiecej) jest jak mała pożyczka, którą zaciągamy aby dostarczyć produkt szybciej. Jednak z każdą niespłaconą pożyczką kolejne wersje będziemy dostarczać odrobinę później.

Zerowy dług technologiczny

Czy to jest w ogóle możliwe? NIE. I tu mógł bym skończyć ale słowo wyjaśnienia, bankowcy mają pojęcie zarządzania długiem. Świat IT też powinien nauczyć się tego. Niektóre długi możemy olać, inne możemy niespłacać latami ale są takie, które należy spłacić odrazu a najlepiej ich nie zaciągać. W każdym projekcie będzie to trochę inaczej wyglądało. Każdy projekt będzie miał w innym miejscu złoty środek minimalnego długu ale należy nauczyć się z tym żyć i nim zarządzać.

Tyle na dzisiaj. Temat ledwo co zarysowałem dlatego w najbliższych wpisach spróbuję się pochylić dokładniej nad poszczególnymi elementami tej układanki.