Dług techniczny to nie synonim bałaganu
Pojęcie zrobiło karierę i po drodze straciło znaczenie. Dziś „dług techniczny" bywa etykietą na wszystko, co komuś w kodzie nie pasuje — od realnego ryzyka produkcyjnego po niezgodę na cudzą konwencję nazewnictwa. To rozmycie ma konkretny koszt: skoro długiem jest wszystko, to biznes przestaje traktować poważnie cokolwiek z tej listy.
Wróćmy do oryginału. Ward Cunningham, który ukuł tę metaforę, mówił o czymś zupełnie innym niż bałagan: o świadomej decyzji, żeby wypuścić rozwiązanie niedoskonałe, ale szybsze, i zapłacić za to później. Dokładnie jak z kredytem — bierzesz go, bo pieniądz dziś jest wart więcej niż pieniądz za rok. Kluczowe słowo brzmi: świadomej.
Bałagan wzięty z niewiedzy nie jest długiem. Jest bałaganem. Różnica nie jest akademicka — decyduje o tym, jak to naprawiać i jak o tym rozmawiać z zarządem.
Cztery typy długu — i tylko dwa warto brać
Najbardziej użyteczny podział rozkłada dług na dwie osie: czy zaciągnąłeś go świadomie i czy była to rozsądna decyzja.
Rozmyślny i roztropny — „wiemy, że to obejście, wypuszczamy przed terminem regulacyjnym, wracamy w Q3". To dług w oryginalnym sensie. Jest w porządku, o ile ktoś zapisał, gdzie go wzięto i kiedy oddać.
Rozmyślny i nieroztropny — „nie mamy czasu na projektowanie, piszemy jak leci". Świadoma decyzja, ale bez planu spłaty. Ten dług nie ma terminu zapadalności, więc rośnie w nieskończoność.
Nierozmyślny i roztropny — „teraz, po roku, wiemy, jak trzeba było to zrobić". Naturalny efekt uczenia się o domenie. Nie da się go uniknąć i nie ma sensu za niego przepraszać; trzeba go tylko odnotować i przy okazji poprawić.
Nierozmyślny i nieroztropny — „a co to jest wzorzec projektowy?". To nie dług, to brak kompetencji. Refactor tego nie naprawi, bo problem odtworzy się w kolejnym module. Naprawia się to mentoringiem, code review i procesem — nie sprintem naprawczym.
Praktyczny wniosek: zanim zaplanujesz spłatę, ustal, z którym typem masz do czynienia. Trzy pierwsze rozwiązuje się technicznie. Czwarty — wyłącznie ludźmi.
Kiedy dług się opłaca
Zespół, który nigdy nie zaciąga długu technicznego, zwykle dostarcza za wolno. Są sytuacje, w których świadomy skrót jest po prostu dobrą decyzją biznesową:
- Walidacja hipotezy. Budujesz funkcję, o której nie wiesz, czy ktokolwiek jej użyje. Wypolerowana architektura pod coś, co za miesiąc zostanie usunięte, to zmarnowany czas. Ta sama logika stoi za tym, co powinno znaleźć się w MVP — i za tym, czego w nim być nie musi.
- Twardy termin zewnętrzny. Wymóg regulacyjny, sezon sprzedażowy, umowa z klientem. Wejść na rynek z obejściem bywa nieporównanie lepiej niż wejść miesiąc później z eleganckim rozwiązaniem.
- Kod o krótkiej przewidywanej żywotności. Migracja jednorazowa, kampania, integracja z systemem, który za pół roku zostanie wyłączony. Inwestowanie w jakość kodu, który sam zniknie, nie zwraca się nigdy.
- Obszar o niskiej zmienności. Moduł, którego nikt nie dotknął od dwóch lat i nie ma powodu dotykać. Brzydki, ale działa — odsetki są tu bliskie zera.
W każdym z tych przypadków dług jest w porządku pod jednym warunkiem: jest zapisany. Komentarz w kodzie z odnośnikiem do zgłoszenia, pozycja w backlogu, notatka w decyzji architektonicznej. Dług nieudokumentowany po pół roku przestaje być decyzją, a staje się zagadką.
Kiedy dług trzeba spłacić — i jak to zmierzyć
Odsetki od długu technicznego są policzalne. To nie metafora — to konkretne liczby, które zwykle już masz w narzędziach.
Czas wdrożenia podobnych zadań rośnie. Najczystszy sygnał. Jeśli funkcja porównywalna do tej sprzed roku zajmuje dziś dwa razy więcej, płacisz odsetki. Porównuj zadania z tej samej kategorii, nie średnie ze sprintu.
Rośnie liczba regresów na wydanie. Naprawa w jednym miejscu psuje coś w drugim — to definicja zbyt silnych powiązań między modułami. Metryka: ile błędów po wydaniu dotyczy obszarów, których wydanie formalnie nie obejmowało.
Wydłuża się czas od merge'a do produkcji. Ręczne kroki, kruche testy, strach przed wdrożeniem w piątek. To dług w procesie, nie w kodzie — zwykle najtańszy do spłaty i najbardziej opłacalny.
Onboarding nowego developera trwa miesiące. Jeśli pierwsze samodzielne zadanie jest możliwe dopiero po ośmiu tygodniach, koszt długu płacisz przy każdej rekrutacji.
Rośnie udział czasu na „utrzymanie" w sprincie. Gdy przekracza mniej więcej połowę, zespół realnie nie rozwija już produktu — obsługuje go. To moment, w którym rozmowa przestaje dotyczyć refactoru, a zaczyna dotyczyć reaktywacji projektu.
Objawy w wersji obserwowalnej z zewnątrz opisaliśmy w tekście 5 znaków, że aplikacja mobilna umiera po cichu.
Osobna kategoria, która nie podlega negocjacji: dług bezpieczeństwa i zgodności. Podatne zależności, sekrety w repozytorium, brak obsługi wymogów regulacyjnych. Tu nie ma dyskusji o priorytecie — jest termin.
Jak rozmawiać o tym z biznesem
Najczęstszy powód, dla którego dług nie zostaje spłacony, nie jest techniczny. Jest komunikacyjny: zespół prosi o „czas na refactor", a decydent słyszy „chcemy kwartał na przestawianie kodu bez efektu, który zobaczy klient".
Cztery rzeczy, które zmieniają tę rozmowę:
Mów o skutku, nie o rozwiązaniu. Nie „musimy zrefaktorować moduł zamówień", tylko „każda zmiana w zamówieniach kosztuje nas trzy dni zamiast jednego i w co czwartym wydaniu powoduje błąd; po uporządkowaniu wróci do jednego dnia".
Podaj liczbę i termin zwrotu. „Dwa tygodnie pracy, zwrot po około czterech miesiącach przy obecnym tempie zmian w tym module." Nawet szacunkowa liczba przenosi rozmowę z kategorii wiary do kategorii inwestycji.
Pokaż, co się stanie, jeśli nic nie zrobimy. Nie jako groźbę, tylko jako projekcję: za pół roku wdrożenie funkcji X zajmie tyle, ryzyko awarii w obszarze Y rośnie, wejście nowej osoby do zespołu kosztuje tyle.
Przypnij spłatę do celu biznesowego. Najskuteczniejszy moment na uporządkowanie modułu płatności to sprint, w którym i tak wchodzi nowa metoda płatności. Refactor „przy okazji" jest tańszy i nie wymaga osobnej zgody.
Bywa, że argumenty nie wystarczają, bo pochodzą od zespołu, który jest w tej sprawie stroną. Wtedy pomaga niezależna ocena z zewnątrz — audyt daje dokładnie to: listę priorytetów, której nikt w firmie nie musi bronić własną reputacją.
Cztery strategie spłaty (i jedna, która nie działa)
Zasada skauta — zostaw kod czystszy, niż go zastałeś. Każde zadanie porządkuje najbliższe otoczenie zmiany. Nic nie kosztuje, nie wymaga zgody, działa w nieskończoność. Ograniczenie: nie ruszy problemów architektonicznych i wymaga dyscypliny w code review.
Stały budżet w sprincie. 15–20% mocy zespołu na dług, planowane jak każda inna praca. Najlepiej sprawdza się w zespołach o stabilnym tempie. Warunek powodzenia: budżet musi być domyślny, nie do wynegocjowania w każdym sprincie z osobna — inaczej zostanie zjedzony przez pierwszą pilną sprawę.
Spłata przy okazji funkcji. Uporządkowanie modułu wchodzi w zakres zadania biznesowego, które i tak go dotyczy. Najlepszy stosunek efektu do wysiłku, bo naprawiasz to, co realnie się zmienia — czyli to, co realnie generuje odsetki.
Wydzielony projekt naprawczy. Kilka tygodni skupionej pracy nad jednym obszarem, z celem i metryką. Uzasadniony przy długu architektonicznym, którego nie da się rozbić na kawałki. Wymaga jasnego zakresu — inaczej rozpływa się w „porządkowaniu".
A strategia, która nie działa: „zrobimy to, jak będzie luźniej". Nigdy nie jest luźniej. Dług, który nie ma przypisanego czasu, właściciela i terminu, nie jest zaplanowany — jest odłożony na zawsze.
Czego nie spłacać
Równie ważna jest lista rzeczy, które warto świadomie zostawić:
- Kod, który się nie zmienia. Jeśli plik nie był modyfikowany od dwóch lat i nie ma powodu, żeby to zmienić, jego brzydota nikogo nic nie kosztuje.
- Systemy z datą wyłączenia. Porządkowanie czegoś, co za pół roku znika, to czysta strata.
- Kwestie estetyczne bez wpływu na zmianę. Preferencje co do stylu rozwiązuje się automatem formatującym, nie zadaniem w backlogu.
- Dług w obszarze, który i tak zostanie przepisany. Jeśli decyzja o przebudowie modułu już zapadła, doraźne łatanie go jest podwójną pracą — o kryteriach tej decyzji piszemy w tekście refactor czy przepisać od zera.
Audyt, który nie mówi, czego nie trzeba robić, jest listą życzeń. To samo dotyczy rejestru długu technicznego.
Podsumowanie
Dług techniczny nie jest wadą procesu — jest jego normalnym elementem, tak jak kredyt w firmie, która rośnie. Groźny staje się dopiero wtedy, gdy nikt go nie zapisuje, nikt nie liczy odsetek i nikt nie ma mandatu, żeby go spłacić.
Trzy rzeczy warto wprowadzić niezależnie od skali projektu: rejestr świadomych skrótów, stały budżet na spłatę i kilka metryk, które pokazują, czy odsetki rosną. To wystarczy, żeby rozmowa o długu przestała być kwartalną kłótnią, a stała się zwykłą pozycją w planowaniu.
Jeśli chcesz, żeby ktoś z zewnątrz ocenił, ile realnie kosztuje Was obecny stan kodu i co z tej listy jest pilne, a co może poczekać — zajmujemy się tym w ramach audytów i konsultacji, a przy dłuższej współpracy również jako wsparcie zespołu IT. Możesz też zacząć od naszej checklisty 15 punktów albo po prostu napisać do nas.