Ship en verbeter

Je kent ze wel, die "tech debt sprints." Twee weken waarin het team stopt met features bouwen en de rommel opruimt. Management haat het. Developers haten het. En de codebase is binnen een maand weer een puinhoop.

Er is een betere manier. En je hebt er geen toestemming voor nodig.

Twee fases. Elke feature.

Fase 1: laat het werken (2 uur)

Maak de feature functioneel. Tests groen. Deployen. Niet gaan zitten polijsten. Het doel is werkende software bij gebruikers, geen museumstuk.

Fase 2: maak het goed (30 minuten, de volgende ochtend)

Frisse blik. Extract het patroon dat je nu drie keer hebt gezien. Hernoem die onduidelijke variabele. Voeg het ontbrekende type toe. Commit, door naar de volgende.

Waarom de volgende ochtend? Omdat je dan frisse ogen hebt maar nog steeds in de context zit. Het is geen aparte taak. Het is het einde van de huidige.

De Boy Scout Rule

Laat de camping schoner achter dan je hem aantrof.

Elk bestand dat je aanraakt, maak je een tikje beter. Geen herschrijving. Geen refactor. Gewoon een betere variabelenaam. Een geextraheerde helper. Een type-annotatie erbij.

Na een paar weken telt het op. Wat begon als losse kleine verbeteringen is opeens een stuk schonere codebase. Zonder dat je ooit een "cleanup sprint" hoefde in te plannen.

Wanneer verbeteren, wanneer overslaan

Simpeler dan je denkt. Stel jezelf een vraag: zit ik hier toch al in?

Signaal	Actie	Budget
Tests slagen, code is leesbaar	Shippen	0 min
Dit patroon twee keer gekopieerd	Nu extracten (Rule of Three)	30-60 min
Functie is 200+ regels	Opsplitsen voor je meer toevoegt	20-40 min
Verwarrende variabelenamen	Hernoemen, je hebt nu context	5-10 min
Security of data-integriteitsrisico	Fixen voor je shipt	Wat nodig is
Probleem in een andere module	Overslaan, noteer in debt register	0 min

Zit je al in het bestand? Dan is verbeteren goedkoop. Moet je naar een andere module switchen? Noteer het en ga door.

Het technical debt register

Een simpel markdown bestand dat bijhoudt welke schuld de moeite waard is. Geen backlog die eindeloos groeit. Een levend document dat je elke week doorneemt.

### TD-012: Dubbele auth-logica in 4 endpoints
- **Impact:** Medium
- **Trigger:** Volgende keer dat we een endpoint toevoegen aan deze module
- **Schatting:** 1 uur
- **Status:** Open

Het trigger veld is de sleutel. Het vertelt je wanneer je deze schuld aflost. Niet "ooit." Maar "de volgende keer dat je toch al aan deze code werkt." Dan zijn de contextkosten het laagst.

Echte resultaten

Metriek	Resultaat
Features geshipt (6 maanden)	40 (geen feature freeze)
Tijd verloren aan refactoring	45 uur (verspreid over 6 maanden)
Code-duplicatie na maand 6	7% (vs. 18% met big-bang sprints)
Velocity-trend	Stabiel/stijgend

Vergelijk dat met de big-bang aanpak. Twee weken stilstand. 40+ nieuwe bugs. Een zaagtand-velocity die elk kwartaal zakt zodra de "tech debt sprint" op de kalender verschijnt.

De Rule of Three betaalt zich uit

Feature-type	Eerste keer	Vijfde keer	Versnelling
CRUD endpoint	3 dagen	4 uur	6x
Gefilterde lijst	2 dagen	3 uur	5x
Notification handler	1 dag	45 min	11x

Die 30 minuten extractie bij de derde keer? Betaalt zichzelf terug bij elke feature daarna.