Teknisk gæld er kløften mellem hvordan koden er og hvordan den burde være, påtaget (bevidst eller ej) for at kunne bevæge sig hurtigere. Noget gæld er fint; jobbet er at administrere det, ikke eliminere det. Nøglen er at prioritere den gæld, der faktisk gør skade.
Prioriter efter virkning, ikke 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
Et konkret eksempel
En skrøbelig modul, der går i stykker ved hver udgivelse og blokerer teamet ugentligt, er værd at rette. Et grimt-men-stabilt værktøj, som ingen rører, er , selvom det fornærmer dig. Refactoring af det er forfængelighed, ikke værdi.