Jak identyfikujesz, ustalasz priorytety i spłacasz dług techniczny?

Question

Accepted Answer

**Dług techniczny** to różnica między stanem kodu a stanem, w jakim powinien być, zaciągnięty (celowo lub nie) aby poruszać się szybciej. Pewna ilość długu jest dopuszczalna; zadaniem jest nim zarządzać, a nie go eliminować. Kluczowe jest ustalenie priorytetów długu, który faktycznie *szkodzi*.

## Dlaczego to ważne

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## Konkretny przykład

Kruchý moduł, który się psuje przy każdym wydaniu i blokuje zespół co tydzień, warto naprawić. Brzydki, ale stabilny narzędzie, którego nikt nie dotyka, *nie jest* warte, nawet jeśli Cię oburza. Refaktoryzacja to próżność, a nie wartość.

## Jak sfinansować pracę

Czysty "sprinty długu" rzadko otrzymują zatwierdzenie. Lepsze taktyki:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Dlaczego to ważne

Niezarządzany dług komplikuje się: prędkość powoli spada, aż zespół prawie nie może dostarczać.

Ale pościg za każdą niedoskonałością marnuje czas na dług, który nie ma znaczenia.

Wartością TL jest wiedza o różnicy i przedstawienie przypadku liderom w kategoriach *biznesowych*, a nie tylko inżynieryjnych.