Cum identifici, prioritizezi și plătești datoria tehnică?

Question

Accepted Answer

**Datoria tehnică** este diferența dintre modul în care este codul și cum ar trebui să fie, asumat (deliberat sau nu) pentru a merge mai repede. Puțin debt este acceptabil; sarcina este să-l gestionezi, nu să-l elimini. Cheia este prioritizarea datoriei care cu adevărat *dăunează*.

## Prioritizează după impact, nu după nemulțumire

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

## Un exemplu concret

Un modul fragil care se rupe la fiecare lansare și blochează echipa săptămânal merită să fie remediat. Un utility urât dar stabil pe care nimeni nu-l atinge *nu*, chiar dacă te ofendează. Refactorizarea lui este vanitate, nu valoare.

## Cum finanțezi munca

Sprinturile pure "debt" rareori sunt aprobate. Tactici mai bune:

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

## De ce conteaza

Dataoria negestionate se agravează: viteza scade liniștit până când echipa abia mai poate livra.

Dar urmărirea fiecărei imperfecțiuni risipește timp pe datoria care nu conteaza.

Valoarea unui TL este să cunoască diferența și să prezinte cazul conducerii în termeni *de afaceri*, nu doar de inginerie.