Hur identifierar, prioriterar och betalar du ned teknisk skuld?

Question

Accepted Answer

**Technical debt** är gapet mellan hur koden är och hur den borde vara, som tas på sig (avsiktligt eller inte) för att röra sig snabbare. Viss skuld är fine; jobbet är att hantera den, inte eliminera den. Nyckeln är att prioritera den skuld som faktiskt *skadar*.

## Prioritera efter påverkan, inte irritation

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

## Ett konkret exempel

En skör modul som går sönder vid varje release och blockerar teamet varje vecka är värd att fixa. Ett fullt-men-stabilt utility som ingen rör är *inte*, även om det förolämpar dig. Refaktorering är fåfänga, inte värde.

## Hur man finansierar arbetet

Rena "skuld-sprintar" blir sällan godkända. Bättre taktiker:

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

## Varför det betyder något

Ohanterad skuld förvärras: hastigheten sjunker tyst tills teamet knappast kan leverera något.

Men att jaga varje imperfection slösar tid på skuld som inte spelar någon roll.

En TL:s värde är att veta skillnaden och göra argumentet för ledarskapet i *affärs*termer, inte bara ingenjörsmässiga.