Elke codebase heeft technical debt. Dat is normaal en zelfs gezond - bewuste trade-offs maken om sneller waarde te leveren is een teken van goede engineering. Het probleem begint wanneer de schuld zo hoog oploopt dat elke wijziging een gevecht wordt. Wanneer grijp je in, en hoe maak je de business case?

Niet alle technical debt is gelijk

Ward Cunningham's originele metafoor van technical debt ging over bewuste keuzes: je weet dat de code beter kan, maar je kiest ervoor om nu te shippen en later te verbeteren. Dat is strategische schuld.

In de praktijk zien we vier typen:

Bewuste, strategische schuld. "We weten dat dit geen ideale oplossing is, maar we moeten deze deadline halen en we refactoren het in Q2." Dit is acceptabel zolang je het ook daadwerkelijk oppakt.

Onbewuste schuld door gebrek aan kennis. Het team wist op dat moment niet dat er een betere aanpak was. Dit is onvermijdelijk en wordt pas zichtbaar als het team groeit in kennis.

Bit rot. De code was ooit prima, maar de wereld is veranderd. Frameworks zijn verouderd, dependencies worden niet meer onderhouden, patronen die vijf jaar geleden best practice waren zijn nu anti-patterns.

Reckless schuld. "We hebben geen tijd voor tests" of "architectuur is overhead." Dit is geen schuld - dit is wanbeleid dat exponentieel terugkomt.

De signalen dat het kritiek wordt

Technical debt is abstract tot je de concrete symptomen herkent:

  • Doorlooptijd stijgt. Features die vergelijkbaar zijn met wat je een jaar geleden bouwde duren nu twee of drie keer zo lang. Niet omdat ze moeilijker zijn, maar omdat de codebase tegenwerkt.
  • Bug-rate stijgt. Elke fix introduceert nieuwe problemen. Het systeem is zo verweven dat lokale wijzigingen onvoorspelbare effecten hebben.
  • Onboarding duurt steeds langer. Nieuwe teamleden hebben weken nodig om productief te worden omdat niemand de code kan uitleggen.
  • Angst voor deployment. Het team deployt liever op vrijdag niet - of het liefst helemaal niet. Dat is een symptoom van een systeem dat je niet vertrouwt.
  • Workarounds stapelen zich op. De code zit vol met "tijdelijke" oplossingen die al jaren meegaan. Elk nieuw feature-verzoek vereist eerst drie workarounds.

De business case bouwen

Technical debt aanpakken kost tijd en geld. Zonder een heldere business case krijg je geen buy-in van stakeholders. Hier zijn argumenten die werken:

Kwantificeer de vertraging. Meet hoeveel langer features duren dan nodig. Als een feature die twee weken zou moeten kosten er zes kost door technical debt, is dat vier weken verloren capaciteit. Reken dat door op jaarbasis.

Tel de incidenten. Hoeveel productie-incidenten zijn direct herleidbaar tot technical debt? Wat kost een incident aan uren, omzetverlies en klantimpact?

Bereken het onboarding-verlies. Als een nieuwe developer drie weken nodig heeft om productief te worden in plaats van één, verlies je twee weken per hire. Bij vijf hires per jaar is dat tien weken - bijna een kwartaal aan verloren productiviteit.

Benoem het risico. Verouderde dependencies met bekende kwetsbaarheden, frameworks zonder security-updates, of compliance-gaps die audits niet overleven - dit zijn concrete risico's die de business begrijpt.

Refactoren vs. herschrijven

De klassieke vraag. Het antwoord is bijna altijd: refactoren, niet herschrijven.

Herschrijvingen falen vaker dan ze slagen. Joel Spolsky schreef er in 2000 al over, en de redenen zijn niet veranderd: je onderschat de complexiteit van het bestaande systeem, je verliest impliciete business rules die in de code zitten maar niet gedocumenteerd zijn, en je moet het bestaande systeem onderhouden terwijl je het nieuwe bouwt.

Het Strangler Fig Pattern is vrijwel altijd de betere aanpak: bouw nieuwe functionaliteit in een nieuwe structuur en migreer bestaande functionaliteit geleidelijk. Je levert continu waarde terwijl je de technical debt afbouwt.

Uitzonderingen bestaan: als de technologiestack zo verouderd is dat je geen developers meer kunt vinden, of als het systeem fundamenteel niet aan nieuwe requirements kan voldoen, dan kan een herschrijving gerechtvaardigd zijn. Maar doe het met open ogen over de risico's.

Een structurele aanpak

  • Maak schuld zichtbaar. Onderhoud een tech debt backlog met geschatte impact. Niet als eindeloze wensenlijst, maar geprioriteerd op business impact.
  • Reserveer structureel capaciteit. Twintig procent van de sprint-capaciteit voor technische verbetering is een veelgebruikte vuistregel. Niet als iets dat wegvalt zodra er druk is, maar als vast onderdeel van je planning.
  • Koppel aan waarde. Refactor niet in abstracto. Koppel technische verbeteringen aan features die er baat bij hebben. "We refactoren de order-module zodat we het nieuwe retourproces kunnen bouwen" verkoopt beter dan "we refactoren de order-module."
  • Meet het effect. Na een refactoring: is de doorlooptijd verbeterd? Zijn er minder incidenten? Kan het team sneller features leveren? Zonder meting is het een geloofsartikel.

Bij NForza helpen we teams om technical debt strategisch aan te pakken. Niet alles hoeft perfect - maar de kritieke paden in je software verdienen wel structurele aandacht. We brengen de ervaring mee om te beoordelen waar ingrijpen de meeste impact heeft.