Hoe identificeer, prioriteer en betaal je technische schuld af?

Question

Accepted Answer

**Technische schuld** is het gat tussen hoe code is en hoe het zou moeten zijn, opgebouwd (bewust of onbewust) om sneller te gaan. Enige schuld is prima; de taak is het beheren, niet elimineren. Het gaat erom de schuld te prioriteren die echt *pijn doet*.

## Prioriteer op impact, niet op ergernis

```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
```

## Een concreet voorbeeld

Een fragiele module die bij elke release breekt en het team wekelijks blokkeert, is het waard om te fixen. Een lelijk-maar-stabiel hulpprogramma dat niemand aanraakt, is dat *niet*, zelfs niet als het je stoort. Het refactoren ervan is ijdelheid, geen waarde.

## Hoe het werk financieren

Zuivere "schuld-sprints" krijgen zelden goedkeuring. Betere tactieken:

```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"
```

## Waarom het belangrijk is

Onbeheerde schuld groeit: snelheid daalt stilletjes totdat het team nauwelijks meer kan uitbrengen.

Maar elk onvolledigheid najagen kost tijd aan schuld die niet uitmaakt.

De waarde van een TL is weten wat het verschil is en een zaak maken voor leiderschap in *bedrijfs*termen, niet alleen technische.