W 1992 Ward Cunningham wymyślił metaforę długu technologicznego, żeby wytłumaczyć szefowi, dlaczego zespół musi refaktorować produkt finansowy. Trzydzieści lat później większość firm IT nadal ma z tym problem.
Nie dlatego, że nie rozumieją metafory. Problem polega na tym, że dług technologiczny nie działa jak dług finansowy. Nikt nie przychodzi w wyznaczonym terminie i nie zabiera serwerów za nieopłacone odsetki.
Kwadrant, który mówi więcej niż backlog
Martin Fowler w 2009 roku stworzył Technical Debt Quadrant, który dzieli dług na cztery kategorie: rozmyślny i nieświadomy, rozważny i lekkomyślny. To najbardziej użyteczna klasyfikacja, jaką widziałem. Zespół, który w piątek popołudniu wrzuca poprawkę z komentarzem “musimy wysłać teraz, potem naprawimy”, wie dokładnie, co robi. Dług rozmyślny i rozważny. Zespół, który po pół roku spojrzenia na własny kod mówi “teraz wiemy, jak powinniśmy to zrobić od początku”, ma dług nieświadomy. Nie wiedział, dopóki nie zbudował.
Problem z długiem nieświadomym polega na tym, że nie da się go uniknąć. Brooks w “The Mythical Man-Month” z 1975 roku pisał, że oprogramowanie rośnie, zmienia się, wymaga konserwacji. Cunningham trzydzieści lat temu mówił, że dostarczenie kodu po raz pierwszy to jak zaciągnięcie długu. Dopóki go nie spłacisz poprzez refaktoring, płacisz odsetki w postaci zwiększonego kosztu każdej zmiany.
SonarQube policzy, ale nie zapłaci za ciebie
Narzędzia takie jak SonarQube próbują kwantyfikować dług. Mierzą złożoność cyklomatyczną, code smells, czas potrzebny na naprawę. Wskaźnik długu technologicznego w Sonarze to koszt naprawy podzielony przez koszt wytworzenia. Prosta formuła. Liczba, którą można pokazać zarządowi.
Tylko że zarząd nie płaci długu technicznego. Płaci go zespół, każdego dnia, gdy próbuje dodać nową funkcję do systemu, który zbudowano na skrótach. Steve McConnell w materiałach dla Construx Software pisał, że dług techniczny pojawia się celowo albo przypadkowo. Celowy dług to decyzja biznesowa. Przypadkowy to brak dyscypliny albo umiejętności. Oba kosztują, ale jeden przynajmniej kupił czas.
Widziałem projekty, gdzie backlog naprawczy miał siedemset pozycji. Nikt nie zamierzał ich spłacać. Były jak długi wykaz grzechów, który wszyscy znali na pamięć, ale nikt nie miał zamiaru iść do spowiedzi.
Odsetki płacisz w tempie zmian
Prawdziwy koszt długu nie jest w backlogu. Jest w tym, że funkcja, którą kiedyś dodawałeś w dwa dni, teraz zajmuje tydzień. Jest w tym, że nowy członek zespołu potrzebuje miesiąca, żeby zrozumieć moduł, który powinien być jasny po trzech dniach. Jest w bugach, które wracają po każdym deployu, bo system zbudowano na założeniach, które przestały być prawdziwe trzy lata temu.
Brooks pokazał, że dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej. Dług techniczny działa podobnie. Im dłużej czekasz ze spłatą, tym trudniej spłacić. Kod, który był “tymczasowy” w 2018 roku, w 2023 ma wokół siebie tyle zależności, że nikt nie wie, co się stanie, gdy go zmienisz.
Nie ma srebnej kuli, ale jest retrospekcja
Zarządzanie długiem technicznym nie polega na tym, żeby go nie mieć. Polega na tym, żeby wiedzieć, ile go masz, ile kosztuje i kiedy zamierzasz spłacić. Zespoły, które działają, robią trzy rzeczy. Po pierwsze, nazywają dług jawnie w momencie jego zaciągania. “Robimy to na skróty, bo release jest za tydzień, ale w przyszłym sprincie wracamy”. Po drugie, rezerwują czas na spłatę. Dwadzieścia procent sprintu, piątek po każdym wydaniu, cokolwiek. Po trzecie, mierzą tempo. Nie liczbą story pointów, ale czasem, jaki zajmuje dodanie funkcji tego samego typu co pół roku temu.
Widziałem firmę, która wprowadziła zasadę: każdy feature branch musi zostać zmergowany albo usunięty w ciągu dwóch tygodni. Brzmi brutalnie. W praktyce zmusiło zespół do rozmowy o tym, co naprawdę jest priorytetem. Długi kod, który czeka na “lepsze czasy”, to dług, którego nikt nie zamierza spłacić.
Dług technologiczny nie zniknie, bo poczekasz. Rośnie, jak każdy inny dług, na którym przestałeś płacić raty.
Źródła
- Cunningham W., “Technical Debt”, Wikipedia contributors, 1992 (metafora wprowadzona na konferencji OOPSLA).
- Fowler M., “Technical Debt Quadrant”, martinfowler.com, 2009.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
- McConnell S., “Managing Technical Debt”, Construx Software, 2008.
- SonarSource, dokumentacja SonarQube dotycząca metryk długu technicznego.
Zdjęcie: www.kaboompics.com / Pexels
