Technical debt is als rente: je merkt het niet bij elke betaling, maar over een jaar telt het flink op. Voor MKB-bedrijven die hun software willen schalen is het herkennen en aanpakken van tech debt een van de belangrijkste vaardigheden — en een van de meest verwaarloosde.
Wat is technical debt eigenlijk?
Technical debt is alle code, architectuur en processen die ooit "tijdelijk" waren en nu de standaard zijn. Een quick fix die nooit is opgeruimd. Een library waar de documentatie niet meer klopt. Een database schema dat 10 jaar geleden goed leek.
Het is niet per se "slechte code". Vaak is het code die ooit prima was, maar waar de wereld eromheen is veranderd.
De 5 symptomen die wijzen op tech debt
1. Releases duren langer dan vroeger
Een nieuwe feature deployen kostte 2 dagen, nu kost het 2 weken? Klassiek tech debt symptoom. De code is verstrengeld geraakt — een wijziging op één plek raakt onverwacht zes andere.
2. Bugs komen terug
Je fixt een bug, hij komt twee maanden later in een andere vorm terug. Of: je fixt iets in module A, en module B breekt. Dit is strakke koppeling — een sleutel-symptoom van architectural debt.
3. Niemand durft de code te raken
"Die module mag niemand aanpassen behalve Jeroen, en Jeroen heeft net opgezegd." Bus factor 1. Dat is geen kennisprobleem — dat is een tech debt probleem dat zich uit als kennisprobleem.
4. Tests doen niet wat ze moeten doen
Je hebt 60% test coverage maar productie-bugs slippen erdoor. De tests testen verkeerde dingen, of zijn brittle (breken bij elke kleine wijziging). Test debt is technical debt.
5. Documentatie en code lopen uit elkaar
De wiki zegt X, de code doet Y. Nieuwe collega's begrijpen het niet. Dat is geen documentatie-probleem — dat is een teken dat de code complexer is geworden dan het mentale model dat documentatie probeert vast te leggen.
Hoe meet je tech debt?
Pure metrics zoals "code coverage" of "cyclomatic complexity" zeggen weinig. Wat wel telt:
- Lead time voor wijzigingen — hoe lang duurt het van idee naar productie?
- Change failure rate — % deploys die rollback of hotfix vereisen
- Time to recover — hoe snel ben je weer up na een incident?
- Onboarding tijd — hoe lang voor een nieuwe dev productief is?
Trekt één van deze metrics omhoog over de tijd? Dat is tech debt die zich opbouwt.
Wanneer pak je tech debt aan?
Niet alle tech debt is het waard om op te ruimen. Drie criteria:
1. Frequentie van wijziging
Code die je elke maand aanpast: refactoring loont. Code die niemand al 3 jaar heeft aangeraakt: laat staan. "Working ugly code" is geen probleem.
2. Business impact
Vertraagt deze tech debt features die geld opleveren? Verhoogt het risico op outages? Dan heeft refactoring meetbare ROI. Anders is het cosmetica.
3. Complexiteit van de fix
Sommige tech debt is vrijwel niet meer op te ruimen zonder herbouw. Die rekening is afgeschreven — leef ermee, maar bouw nieuwe modules ernaast in plaats van fixes erin.
Een framework: het 20% regel
Toonaangevende teams reserveren 20% van hun sprint-capaciteit voor tech debt. Niet als aparte "refactor sprint" (die wordt altijd geschrapt), maar als deel van elke feature.
"Bij ons werkt het zo: elke user story heeft naast functionaliteit ook een opruim-component. Bouw je een nieuw scherm? Refactor de gerelateerde service tegelijk. Tech debt verdwijnt geleidelijk in plaats van in mega-projecten."
De grote uitzondering: rewrite-vallen
"We bouwen het systeem helemaal opnieuw" klinkt vaak als de oplossing. Het is bijna nooit het antwoord. Rewrites duren 2-3x langer dan gepland, missen requirements die in de oude code verstopt zaten, en in de tussentijd staat business stil.
Beter: strangler fig pattern. Bouw nieuwe functionaliteit als aparte service ernaast. Verlaag stuk-voor-stuk de afhankelijkheid van de oude code. Na 12-18 maanden is het oude systeem leeg en kun je het uitzetten.
Praktische volgende stappen
- Meet: track lead time, change failure rate en MTTR voor 4 weken
- Identificeer hotspots: welke 20% van je code zorgt voor 80% van wijzigingen?
- Reserveer capaciteit: 20% per sprint, structureel
- Begin klein: pak één hotspot per kwartaal echt aan
- Communiceer ROI: laat zien hoe lead time daalt na refactoring
Worstelt je team met tech debt en weet je niet waar te beginnen? Wij doen code-audits voor MKB-teams — concrete bevindingen, prioritering, en een plan dat past bij je business. Geen academisch verhaal.
Lees ook: Microservices vs monoliet — vaak is microservices meer tech debt dan oplossing.