TL;DR: Dług techniczny nie jest kategorią moralną, a „ten kod jest brzydki" nie jest argumentem, który ktokolwiek sfinansuje. Opisuj każdy dług jego stopą procentową — tym, co kosztuje przy każdym wdrożeniu, review, debugowaniu i onboardingu — wpisz te koszty do tabeli czytelnej dla ludzi od produktu i spłacaj tuż przed momentem, w którym dług stanie się podatkiem koordynacyjnym, najlepiej przy okazji pracy na tej samej granicy.
Nie każdy dług ma taką samą stopę
Oryginalna metafora Warda Cunninghama była precyzyjna: dług pozwala wydać szybciej, a odsetki naliczają się, dopóki nie spłacisz kapitału. To, co zespoły zrobiły z metaforą, było mniej precyzyjne — „dług techniczny" stał się synonimem „kodu, który mi się nie podoba", co odarło pojęcie z jego jedynej użytecznej właściwości: idei stopy procentowej.
Część długu jest tania i celowa — zahardkodowany config w usłudze, która i tak zostanie przepisana w przyszłym kwartale, nie kosztuje prawie nic. Część nalicza odsetki od każdej transakcji zespołu: od każdego release'u czekającego na ręczny krok, każdego review wymagającego archeologii, każdego onboardingu trwającego tygodnie, bo kształt systemu żyje w głowach trzech osób.
Pytanie nigdy nie brzmi „czy to dług?" — wszystko nim jest, w jakimś stopniu. Pytanie brzmi: „jaka jest stopa i kto ją płaci?".
Traktowanie długu jako winy moralnej daje dwa złe skutki: inżynierowie czują wyrzuty z powodu długu, który jest w porządku, a naprawdę drogi dług chowa się w tej samej niezróżnicowanej stercie co nieszkodliwy.
Robocza taksonomia
Kwadrant Fowlera — celowy kontra nieświadomy, rozważny kontra lekkomyślny — dobrze otwiera rozmowę, ale do planowania używam ostrzejszej klasyfikacji według zachowania odsetek:
- Dług o stałej stopie. Kosztuje tyle samo, w nieskończoność: niezgrabny, ale stabilny moduł, którego nikt nie dotyka. Często w ogóle nie wart spłaty — a przyznanie tego na głos jest dla zespołu wyzwalające.
- Dług eskalujący. Odsetki rosną z systemem: wspólna baza, która była w porządku przy jednym zespole, a dusi cztery. Najniebezpieczniejsza klasa, bo wczesna taniość maskuje trajektorię.
- Dług procentu składanego. Dług rodzący dług: brak testów czyni refactoring ryzykownym, więc kumulują się obejścia, przez co testy jeszcze trudniej dodać. Takie pętle zasługują na priorytet, nawet gdy bieżący koszt wygląda umiarkowanie.
- Dług na żądanie. Niskie odsetki, dopóki zewnętrzne zdarzenie nie zażąda całego kapitału naraz: runtime po EOL, wygasająca wersja API, termin compliance. Tani do daty, potem nagły stan wyjątkowy. Śledź daty, nie dyskomfort.
Pokaż koszt
Dyskusje o długu grzęzną, bo inżynieria opisuje problem po inżyniersku — coupling, duplikacja, „bałagan" — a produkt nie słyszy niczego, co dałoby się zważyć z funkcją. Wspólną walutą jest koszt zwłoki. Opisz każdy istotny dług przez to, co robi z dostarczaniem, a priorytetyzacja stanie się normalną rozmową:
| Dług | Odsetki (koszt zwłoki) | Typ stopy | Wyzwalacz spłaty |
|---|---|---|---|
| Ręczny proces release'u | Każdy deploy czeka na jedną osobę; wdrożenia w piątki unikane | Eskalująca | Drugi zespół zaczyna wdrażać co tydzień |
| Wspólna baza między usługami | Każda zmiana schematu koordynowana między zespołami; dostarczanie blokuje się | Eskalująca | Podział własności wchodzi na roadmapę |
| Brak testów kontraktowych na API partnera | Regresje integracji docierają na produkcję co miesiąc | Składana | Partner ogłasza comiesięczne zmiany API |
| Legacy moduł raportów, stabilny | Brzydki, ale nietykany od roku | Stała | Prawdopodobnie nigdy — powiedz to wprost |
Zwróć uwagę na ostatni wiersz. Widoczny wpis „świadomie tego nie spłacamy" jest wart tyle, co każdy plan spłaty — zamienia mgliste poczucie winy w decyzję, do której można wrócić, gdy zmienią się fakty.
Gdzie naliczają się odsetki
Szacując stopę, przechodzę przez cztery miejsca, w których odsetki realnie się pojawiają — bo zespoły nawykowo liczą tylko pierwsze:
- Czas dostarczania. To oczywiste — dodatkowe kroki, czekanie, narzut koordynacji na każdą zmianę.
- Jakość review. Obszary ciężkie od długu dostają płytsze review, bo zrozumienie kontekstu kosztuje za dużo. Defekty idą dokładnie tam, skąd uciekła uwaga.
- Zachowanie w incydentach. Dług zamienia małe incydenty w duże: brak ścieżki rollbacku, splątana odpowiedzialność, recovery wymagające tej jednej osoby, która rozumie moduł.
- Onboarding i obsada. System, który bezpiecznie modyfikują tylko trzy osoby, ma wliczone ryzyko kadrowe — tyle że nie widać go na żadnym dashboardzie, dopóki jedna z nich nie złoży wypowiedzenia.
Wybierz moment spłaty
Najlepszy moment przypada zwykle tuż przed tym, jak dług stanie się podatkiem koordynacyjnym — chwilę zanim drugi zespół zacznie zależeć od granicy, zanim ruch się podwoi, zanim partner API przyspieszy. Taki timing wymaga patrzenia na trajektorie, a nie na bieżący ból — i dokładnie po to jest klasyfikacja typów stóp.
Drugi najlepszy moment jest okazjonalny: i tak dotykasz tej granicy przy pracy nad funkcją, kontekst jest załadowany, a krańcowy koszt zrobienia rzeczy porządnie jest na życiowym minimum. Najgorszy moment to ten, który zespoły wybierają najczęściej — po incydencie, w sprincie sprzątania napędzanym poczuciem winy, którego zakres ustawił wstyd, a nie stopy.
Strategie spłaty
Trzy strategie pokrywają niemal wszystkie przypadki, a wybór złej marnuje więcej wysiłku niż wybór spóźniony:
- Przy okazji. Dług w kodzie dotykanym przy funkcjach spłacany jako część tej pracy — zasada harcerska z budżetem, zwykle dziesięć–dwadzieścia procent zmiany. Właściwa dla większości długu o stałej i wolno eskalującej stopie; nie wymaga zgód ani ceremonii.
- Kampania. Dług eskalujący albo składany, którego spłata zajmuje tygodnie, potrzebuje nazwanego, zaplanowanego wysiłku z jawnym warunkiem końca — „wszystkie usługi wdrażają się bez ręcznych kroków", nie „poprawić CI". Właściwa dla wspólnej bazy, procesu release'u, luki testowej. Kampania bez warunku końca to styl życia.
- Duszenie (strangler). Gdy moduł jest poza zasięgiem naprawy przyrostowej — buduj zamiennik obok i przełączaj ruch stopniowo. Drogie, wolne i jedyna uczciwa opcja dla niektórych rdzeni legacy; błędem jest wybieranie jej z dumy, gdy wystarczyłaby kampania.
Dedykowany „sprint na dług techniczny" co kwartał to zwykle objaw, nie lekarstwo — znaczy, że dług nie ma miejsca w normalnym planowaniu, więc dostaje getto. Stopy należą do tego samego backlogu co funkcje i są ważone w tej samej walucie.
Rozmowa z biznesem
Wszystko powyżej wali się bez jednej umiejętności tłumaczenia: opisywania długu w wynikach, na których biznesowi już zależy. „Moduł checkoutu ma wysoki coupling" dostaje uprzejme skinienie. „Każda zmiana w checkoucie trwa trzy tygodnie zamiast jednego i ten stosunek się pogarsza — oto poprawka na dwa sprinty, która to odwraca" dostaje decyzję.
Trzy zasady formułowania, które mi służą: zaczynaj od konsekwencji dla dostarczania, kwantyfikuj trend zamiast stanu (pogarszający się stosunek alarmuje uczciwiej niż zła migawka) i zawsze dołączaj koszt spłaty — nazwana cena zamienia skargę w decyzję inwestycyjną. A kiedy uczciwa analiza mówi, że długu nie warto spłacać — powiedz i to; wiarygodność zarobiona na przypadkach „nie" finansuje te na „tak".
Podsumowanie
- Dług nie jest kategorią moralną — pytaj o stopę procentową, nie o estetykę.
- Klasyfikuj według zachowania stopy: stała, eskalująca, składana, na żądanie. Trajektoria znaczy więcej niż dzisiejszy ból.
- Publikuj tabelę kosztów w języku kosztu zwłoki, z jawnymi wierszami „świadomie nie spłacamy".
- Licz odsetki we wszystkich czterech księgach: dostarczanie, jakość review, incydenty, onboarding.
- Spłacaj tuż przed uderzeniem podatku koordynacyjnego albo okazjonalnie, dotykając granicy.
- Dobieraj strategię do długu: przy okazji, kampania z warunkiem końca albo duszenie — a stopy trzymaj w normalnym backlogu.