Hvordan forklarer du technical debt til et ikke-teknisk publikum?

Question

Accepted Answer

**Jeg oversætter tech debt til det sprog, publikummet allerede bruger: penge, hastighed og risiko.** En ikke-teknisk stakeholder er ligeglad med coupling eller test coverage; de bekymrer sig om, at features bliver langsommere og dyrere at shippe. Så jeg indrammer debt som et finansielt og leveringsmæssigt problem, ikke et kodeproblem.

## Den indramning jeg bruger

- **Den finansielle metafor, brugt forsigtigt.** "Vi tog en genvej for at shippe hurtigt, ligesom at tage et lån. Det virkede, og nu betaler vi renter på det hver sprint. Hver ny feature i dette område koster mere på grund af de renter." Dette lander, fordi alle forstår gæld og renter.
- **Gør det konkret med deres metrikker.** Ikke "koden er rodet", men "denne feature tog tre uger; for to år siden tog samme størrelse én. Forskellen er den vedligeholdelsesomkostning, vi har akkumuleret."
- **Knyt det til de outcomes, de bekymrer sig om.** Langsommere levering, flere bugs der når kunderne, sværere onboarding for nyansatte, stigende risiko for et nedbrud. Forbind debt til omsætning, omdømme og roadmap-hastighed.

## Hvordan jeg gør det til en beslutning, ikke en klage

- Præsentér det som et **trade-off med muligheder**, ikke et krav: "Vi kan blive ved med at shippe features i det nuværende aftagende tempo, eller investere to sprints nu for at skære fremtidig feature-omkostning med cirka en tredjedel."
- Kvantificér hvor jeg kan: tid tabt per sprint, incident-frekvens, procentdelen af kapacitet brugt på brandslukning.
- Vær ærlig om, at **noget debt er fint.** Ikke al debt skal betales; pointen er at betale den debt af, der aktivt belaster leverancen.

## Faldgruber

- **At bruge jargon** ("refactor," "coupling," "arkitekturen er forkert"). Det får dig til at lyde, som om du vil gold-plate koden.
- At indramme det som ingeniører, der vil have ren kode for dens egen skyld; det læses som selvforkælende.
- At råbe ulven kommer — at kalde alt for debt udhuler troværdighed, når noget reelt presserende dukker op.

## Hvorfor det betyder noget

Hvis du ikke kan forklare tech debt i forretningstermer, bliver det aldrig finansieret, og teamet maler langsomt i stå, mens ledelsen undrer sig over, hvorfor velocity falder. At indramme det som omkostning, hastighed og risiko er det, der giver dig tiden til at fikse det, før det bliver en krise.