Widziałem ostatnio fajny film, bazujący na rzeczywistych wydarzeniach, pod tytułem Deepwater Horizon. Oprócz bycia dobrze zrobionym i rozrywkowym, film miał dla mnie dodatkową wartość. Była to historia o tym, co dzieje się z projektem posiadającym niewystarczające testy i krótkowzroczny management wywierający nacisk na wypuszczenie niedokończonego produktu z monstrualnym długiem technicznym.

Otóż projekt eksploduje w wielkiej kuli ognia.

dwhepksocial

Dług techniczny

Ward Cunningham ukuł pojęcie długu technicznego pracując nad systemem finansowym. Ideą jest spostrzeżenie, że gdy tworzymy oprogramowanie możemy często pójść w dwóch kierunkach. Możemy spędzić więcej czasu i zaimplementować nową funkcjonalność czysto, solidnie i biorąc pod uwagę istniejącą architekturę. Jeśli funkcjonalność nie pasuje dobrze do istniejącej architektury czy designu, aplikujemy stosowny wysiłek aby go zmienić. Drugi kierunek to skupienie się na dostarczeniu działającego kodu szybciej, lecz bez należytej troski o system jako całość i jego przyszłość. Całościowy stan kodu ulega pogorszeniu i powinien zostać naprawiony aby możliwe było utrzymanie prędkości zespołu na aktualnym poziomie. Czas, albo pieniądze, który oszczędzamy teraz są długiem, który musi zostać spłacony później. Im później to nastąpi, tym większe odsetki musimy zapłacić oprócz kwoty, którą oryginalnie pożyczyliśmy.

Cichy dusiciel

Niestety, w wielu projektach programistycznych sprawa długu technicznego nie jest należycie zadbana. Nie-techniczni ludzie biznesowi często nie rozumieją tego mechanizmu i wymagają od programistów dodawania kolejnych funkcjonalności tak szybko, jak to możliwe, generując więcej i więcej długu. Tym bardziej nie spłacając tego zaciągniętego już wcześniej. Prowadzi to do sytuacji, gdy praca nad projektem stopniowo i asymptotycznie zwalnia. Nowe rzeczy zabierają coraz więcej i więcej czasu, ponieważ jest coraz trudniej i trudniej wymyślić jak zmienić nieregularny, chaotyczny, paskudny i niezrozumiały system. Jakość spada na łeb, bo takie systemy są bardziej podatne na błędy. Im dłużej to trwa, tym trudniej jest wyjaśnić sytuację biznesowi. „Mówisz, że musimy teraz przestać zarabiać pieniądze na trzy miesiące, żeby zrobić jakieś magiczne zmiany, które nie mają żadnej wartości? Postradałeś zmysły? Klient za to nie zapłaci, bla, bla, bla…” Każdy z nas miał z tym do czynienia. Problem polega na tym, że dochód z nowych funkcjonalności jest tu i teraz i jest mierzalny, podczas gdy zwalczanie długu technicznego kosztuje teraz, ale opłaca się dopiero w dłuższej perspektywie czasowej, a konkretne zyski są bardzo trudne do oszacowania.

technical-debt

Świadomy wybór

Dług techniczny nie musi być koniecznie zły. Podobnie jak dług w życiu. Decydujemy się na zaciągnięcie długu bo możemy na tym zyskać – rozkręcić dochodową firmę, kupić wygodny dom i mieć możliwości, do których nie moglibyśmy inaczej mieć dostępu. Być może nasza firma jest w sytuacji gdy skończenie pewnej rzeczy w danym terminie jest super krytyczne biznesowo. Zarobimy kupę pieniędzy, której inaczej nie zobaczylibyśmy nigdy na oczy, wybierając zaimplementowanie funkcjonalności ostrożnie, z odpowiednimi refaktoringami i zmianami w architekturze. Często jest to optymalna strategia. Równie często fakt, że zaciągnięty dług trzeba spłacić, zostaje później przemilczany. Należy pamiętać, jak mawia Wujek Bob, że dług techniczny jest świadomym wyborem, a nie przypadkiem. Słaby kod jest po prostu słabym kodem, a bałagan jest bałaganem. Decyzje i techniczna niekompetencja to dwie różne sprawy.

Szersza perspektywa

Niektórzy programiści, często niedoświadczeni acz energiczni, mają tendencję do zbawiania świata i spłacania długu na własna rękę. Czasem problemem jest to, że są zbyt gorliwi i brakuje im spojrzenia z lotu ptaka, co może być szczególne bolesne w dużych systemach. A szersza perspektywa może być taka, że jakiś duży fragment tego systemu jest zaplanowany do przepisania od zera, być może dlatego, że trzeba stworzyć bardziej elastyczny silnik bo wymagane funkcjonalności są zbyt trudne do wplecenia w istniejący kod. Jakiś czas temu byłem takim programistą, ale już z tego wyrosłem. Bywał to bolesny proces. Spłacanie długu powinno być świadomą i wykalkulowaną decyzją, podobnie jak wcześniejsze zaciąganie go.

too-busy

Komunikacja

Zatem, jeśli twój kod gnije coraz bardziej, jego rozwój spowolnił do czołgania się, a nowe rzeczy są coraz bardziej bolesne do zaimplementowania, to wiedź, że coś się dzieje. Może to znak że masz dużo długu.

W którymś momencie musisz zaprzestać generowania go i dokonać spłaty.

Tak, to oznacza, że nie będziesz implementował nowych funkcjonalności, ale to jedyna droga. Każda rozsądna osoba rozumie, że w realnym świecie, jeśli zaciągniesz dług, musisz go w którymś momencie spłacić albo doświadczysz nieprzyjemnych konsekwencji. Nie mogę wyjść z zaskoczenia dlaczego niektórzy biznesowi ludzie nie łapią tego w odniesieniu do rozwoju oprogramowania albo zwyczajnie ignorują rzeczywistość.

Co wtedy?

Jako profesjonalny programista, twoją odpowiedzialnością jest edukować tych, którzy wymagają edukacji. Czasem problem bywa głębszy. Twój Product Owner rozumie, jego przełożony rozumie, ale już kolejna osoba w łańcuchu dowodzenia nie. Możesz pokazywać jej te wszystkie fajne wykresy z wykładniczo rosnącymi wartościami i tłumaczyć, że i tak zapłaci za to wszystko, tylko więcej. I ponieważ jakość spada wraz z wzrostem długu technicznego, w ekstremalnych przypadkach ta spłata może mieć formę odszkodowania za platformę, która przestała istnieć w spektakularnej eksplozji, tak  jak Deepwater Horizon.

dragonfire

Rzemieślnik Javy z zacięciem grafomańskim. Zawodowo od 2009 psuje oprogramowanie. Był już w fińskim telecomie, niemieckiej logistyce, szwajcarskim banku, szwedzkiej fabryce aut i finalnie wylądował w polskim software housie. Jest miłośnikiem pięknego kodu, ewangelistą Scruma i molem książkowym. Interesuje się psychologią, fantastyką wszelakiego rodzaju, grami planszowymi, komputerowymi i fabularnymi, japońskimi sztukami walki: Aikido i Iaido oraz duńskimi klockami Lego. Od dwóch lat prowadzi bloga o tresowaniu Javy ze smokiem w tle, dostępnego pod adresem: www.HowToTrainYourJava.com