Kuinka tunnistatte, priorisoitte ja maksat teknistä velkaa?

Question

Accepted Answer

**Tekninen velka** on ero sen välillä, miten koodi on ja miten sen pitäisi olla, ottamasi (tarkoituksella tai ei) päästäksesi nopeammin eteenpäin. Jokin velka on kunnossa; tehtävä on hallita sitä, ei eliminoida sitä. Avain on priorisoida velka, joka todella *vahingoittaa*.

## Priorisoi vaikutuksen perusteella, ei ärsytyksestä

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

## Konkreettinen esimerkki

Kaunis moduuli, joka hajoaa jokaisessa julkaisussa ja estää tiimin viikoittain, kannattaa korjata. Ruma mutta vakaa työkalu, jota kukaan ei kosketa, *ei kannata*, vaikka se loukkaisikin sinua. Sen uudelleenkirjoittaminen on turhuus, ei arvo.

## Kuinka rahoittaa työtä

Puhtaat "velka-sprintit" hyväksytään harvoin. Paremmat taktikat:

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

## Miksi sillä on merkitystä

Hallitsematon velka lisääntyy: nopeus laskee hiljaa, kunnes tiimi tuskin pystyy toimittamaan.

Mutta jokaisen puutteen ajaminen tuhlaa aikaa velkaan, jolla ei ole merkitystä.

Tech Leadin arvo on tietää ero ja esittää tapaus johdolle *liiketoiminnallisin* termein, ei vain teknisin.