Hoe balanceer je het snel leveren van een deadline tegen het goed bouwen voor onderhoudbaarheid?

Question

Accepted Answer

Er is geen absolute antwoord, en dat is het punt. **Snelheid vs. onderhoudbaarheid is contextafhankelijk** — je past de nauwkeurigheid aan op de **inzet** en de **verwachte levensduur** van de code. Een wegwerp-prototype en een betalingskern verdienen zeer verschillende standaarden. De taak van de lead is om die afweging **bewust** te maken, niet om het per ongeluk te laten gebeuren.

## Een raamwerk voor besluitvorming

Stel drie vragen voordat je een hoek afsnijdt:

- **Hoe lang zal dit meegaan?** Een experiment van één week kan rommelig zijn; een kernservice die je jaren onderhoudt, kan dat niet.
- **Wat is de impact als het kapotgaat?** Hogere inzet (geld, gegevens, veiligheid, moeilijk ongedaan te maken wijzigingen) betekent een hogere standaard.
- **Hoe moeilijk is het om dit later te veranderen?** Code die goedkoop te vervangen is, toleriert shortcuts; load-bearing interfaces en datamodellen niet.

## Bewuste vs. onbewuste shortcuts

- Een **bewuste** shortcut heeft een naam, is begrensd, en wordt **als schuld bijgehouden** (een ticket, een `// TODO`, een notitie in de RFC). Je weet precies wat je ingeruild hebt en waarom.
- Een **onbewuste** shortcut is stille kwaliteitserosie — niemand heeft het besloten, niemand houdt het bij, en het verstevigt zich.

Houd de **kern schoon** ook onder druk: goed benoemde grenzen, geteste kritieke paden. Duw de chaos naar de randen waar het goedkoop is om het uit te ruien.

## Onderhandel over de driehoek, snij niet stilzwijgend in de kwaliteit

Wanneer een deadline krap is, is de eerlijke zet om **scope of tijd** met stakeholders te heroveren — niet om stilzwijgend iets brokkelig op te leveren. "We kunnen de deadline halen met feature A en B, maar C verschuift een week" is een echt gesprek. Stilzwijgend fragiele code opsturen geeft de toekomstige snelheid van het team uit zonder dat iemand het ervan bewust is.

## Waarom het belangrijk is

Teams die altijd voor snelheid optimaliseren, verdrinken in schuld; teams die altijd overmatig vergulden missen markten. De waarde van de lead is oordeel — nauwkeurigheid afstemmen op context en de afweging **zichtbaar en in eigendom** maken, zodat de shortcut van vandaag een keuze is die het team kan terugbetalen, niet een verrassing die het erft.