Wprowadzenie
Dla większości z nas „dług technologiczny” to coś, co zmienia z pozoru proste zadanie, szacowane na niewielką liczbę godzin, w coś nieprzewidywalnego, trudnego do dostarczenia klientowi i jednocześnie rujnującego nasze wyceny…
Dług technologiczny jest niczym pożyczka finansowa, która może być dla nas czymś bardzo pomocnym w danej chwili, o ile tylko spłacimy ją na czas w przyszłości. Taki koncept długu technologicznego, który porównuje go do prostego kredytu pieniężnego, zdefiniował po raz pierwszy Ward Cunningham, autor między innymi Agile manifesto. W 1992 roku podczas konferencji OOPSLA („Object-oriented Programming, Systems, Languages, and Applications”) Ward uzupełnił definicję długu technologicznego o dodatkowe wyjaśnienie:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise”.
Wbrew powszechnej opinii dług technologiczny nie jest wyłącznie czymś negatywnym dla projektu. W wielu sytuacjach jest on pomocnym narzędziem podczas budowania testowych rozwiązań. Jednakże jednocześnie nie można o nim zapominać.
Wszyscy mamy z nim do czynienia
Z pewnością każdy, kto pracował w większej liczbie projektów, miał do czynienia z długiem technologicznym. Być może nie wiedzieliśmy, że tak to się nazywa, ale z pewnością, napotkaliśmy takie sytuacje, gdy zupełnie błahy task, który w normalnych warunkach nie powinien zająć wiele czasu, zmieniał się w coś niesłychanie skomplikowanego i czasochłonnego. Często, żeby dokończyć bardzo prostą sprawę, musieliśmy po drodze naprawić niezliczoną liczbę innych niedociągnięć w projekcie. Niekiedy całkiem zaniechaliśmy dalszych prac, ponieważ ich realizacja była niemożliwa z powodu zbyt niskiej wyceny, a z kolei wyższa wycena powodowała, że wykonywany task stawał się nieopłacalny z punktu widzenia klienta.
Dług technologiczny jest także wrogiem wycen. Nie wiedząc, z jakim długiem technologicznym mamy do czynienia w projekcie, nie jesteśmy w stanie dokonywać rzetelnych wycen. Proste sprawy komplikują się, a często bez zagłębiania się w projekt nie możemy ocenić, na ile dług technologiczny istniejący w projekcie przeszkodzi nam w realizacji zadania. Ostatecznie jesteśmy zmuszeni narzucać dodatkowy margines błędu na każdą wycenę, a klient jest niezadowolony z kosztów, jakie ponosi, i ostatecznie kończy na poszukiwaniu tańszych specjalistów.
Warto w tym momencie zaznaczyć, że dług technologiczny nie musi dotyczyć wyłącznie projektów, które nam się „nie udały”. Często świadomie podejmujemy decyzję o wprowadzeniu pewnych rozwiązań, które spowodują wzrost ryzyka długu, ale jednocześnie przyniosą nam większą korzyść niż stratę…
Nie każdy dług jest zły
Istnieje kilka przypadków, w których dług technologiczny staje się przydatnym narzędziem w procesie budowania projektu. Możemy wyróżnić przede wszystkim dwie sytuacje, w których możemy mówić o pozytywnym wpływie długu technologicznego.
Budujemy MVP
Jesteśmy start-upem albo przychodzi do nas klient, który nie jest pewny swojego pomysłu, i mamy ograniczony budżet oraz czas na zbudowanie konkretnej aplikacji czy też konkretnego rozwiązania. W takiej sytuacji, nie chcąc rezygnować ze swojego pomysłu albo nie chcąc stracić zainteresowanego klienta, możemy podjąć decyzję o świadomym długu technologicznym.
Dzięki temu możemy znacznie przyspieszyć proces budowania aplikacji i testowego wdrożenia dla klientów, ale musimy być świadomi jednej rzeczy. Prędzej czy później (zawsze lepiej wcześniej niż później) będziemy musieli porzucić zbudowaną przez nas aplikację i jednocześnie wraz z rozwojem projektu czy też w związku z większym zainteresowaniem naszym produktem będziemy zmuszeni zbudować aplikację od nowa. Jeśli tego nie zrobimy, w dłuższej perspektywie dług technologiczny może być nie do nadrobienia i może okazać się zabójczy dla naszego projektu – lub nawet całego biznesu, jeśli swój biznes oparliśmy wyłącznie na takiej „wadliwej” aplikacji.
Nie znamy przyszłości
Drugą sytuacją, w której możemy podjąć ryzyko świadomego zwiększenia długu technologicznego, jest przypadek, kiedy my albo nasz klient nie jesteśmy pewni przyszłości aplikacji i tego, jak będzie ona kiedyś wyglądać.
Jest to sytuacja podobna do tej z MVP, tyle że tutaj naszym wrogiem nie będzie czas, a po prostu brak wiedzy związanej z biznesową przyszłością aplikacji. W tym przypadku również możemy spodziewać się, że w pewnym momencie, kiedy kierunek rozwoju zostanie już ostatecznie obrany, będziemy musieli się liczyć z napisaniem aplikacji od nowa. Jednakże możemy również założyć, że dysponując odpowiednią ilością czasu, będziemy mogli na bieżąco redukować dług technologiczny i w ten sposób unikniemy pisania aplikacji od nowa.
W tej sytuacji musimy tylko pamiętać o jednym. Nie można mylić braku wiedzy co do przyszłości aplikacji z brakami technicznymi lub niedostatkiem informacji na temat wykorzystywanych technologii. Jeśli nie mamy wiedzy na temat tego, jak rozwiązać dany problem, i wybierzemy złe technologie lub narzędzia, to nie możemy liczyć na to, że kiedyś taki dług będzie nam łatwo nadrobić…
Wpływ na morale zespołu
Rozmawiając o długu technologicznym, nie możemy zapominać o jego znaczącym wpływie na morale zespołu. Każdy z programistów zdaje sobie sprawę z tego, że praca nad projektem obarczonym dużym długiem technologicznym jest męcząca. Niestety, często bywa tak, że managerowie danych projektów (project manager, scrum master itd.) o tym zapominają, przez co u programistów dochodzi do „wypalenia się” w danym projekcie, a ich efektywność znacząco spada. To z czasem może prowadzić do jeszcze poważniejszych konsekwencji, jak odejścia z projektów czy z firmy, a nawet może doprowadzić do ogólnego wypalenia się danego programisty w jego zawodzie.
Z uwagi na te zagrożenia warto rozmawiać o takich sytuacjach ze swoim zespołem. Pierwszym i znaczącym sygnałem dla managerów, że projekt może być obarczony dużym długiem technologicznym, jest sytuacja, w której coraz częściej dochodzi do przekraczania wycen w taskach lub wyceny z miesiąca na miesiąc coraz bardziej rosną. W tym momencie należałoby omówić z zespołem, z czego wynikają te problemy, i jeśli powodem jest dług technologiczny, to należałoby podjąć konkretne kroki w celu jego redukcji.
O narzędziach i sposobach walki z długiem technologicznym będzie można poczytać wkrótce we wpisie 10 sposobów walki z długiem technologicznym.
Podsumowanie
O ile dług technologiczny w większości przypadków jest czymś, co wpływa negatywnie na cały projekt, o tyle istnieje kilka sytuacji, w których może on stać się przydatnym narzędziem w pracy nad projektem. Jednakże takich sytuacji jest niewiele i na co dzień powinniśmy z nim raczej walczyć, niż go powiększać.
Istnieją zasadniczo dwa rodzaje długu technologicznego: taki, który tylko „zrani” nasz projekt, i taki, który może „zabić” nasz projekt. Długiem pierwszego rodzaju może być chociażby brak testów, źle zaprojektowana struktura kodu, brak code review lub brak dokumentacji. Znacznie gorzej, jeśli podczas pracy nad projektem popełniliśmy takie błędy jak zły dobór technologii, źle zaprojektowana struktura danych czy też wybór zależności, nad którymi nie panujemy i które nie są już wspierane oraz aktualizowane. W takiej sytuacji próby naprawy tych błędów będą znacznie trudniejsze i może nadejść moment, w którym jedynym rozwiązaniem stanie się przepisanie projektu od nowa.
Maciej Mortek
