Technische schuld (in het Engels technical debt of tech debt) is het werk dat je later moet doen omdat software eerder sneller, goedkoper of eenvoudiger is gebouwd dan eigenlijk nodig was, of omdat de technologie eromheen is verouderd. Het lijkt een technisch begrip, maar de gevolgen merk je vooral in je bedrijfsvoering: trage doorontwikkeling, onverwachte storingen en verborgen kosten.
Wij komen technische schuld dagelijks tegen in applicaties die we overnemen. Dat is geen verwijt aan de vorige developer. Technische schuld is tot op zekere hoogte onvermijdelijk. De vraag is of je hem beheerst.
Wat is technische schuld precies?
De term technical debt is een metafoor die volgens Martin Fowler werd bedacht door Ward Cunningham. De vergelijking met een financiële schuld werkt goed:
- De hoofdsom is het werk dat nodig is om de code of architectuur op orde te brengen.
- De rente is de extra inspanning die elke nieuwe wijziging kost zolang je dat niet doet.
Een snelle oplossing om een deadline te halen is dus een lening. Dat kan een slimme investering zijn. Maar wie nooit aflost, betaalt steeds meer rente, tot er nauwelijks ruimte overblijft voor nieuwe functionaliteit en innovatie.
Technische schuld en legacy code
Legacy code is oudere code die nog in gebruik is, vaak geschreven door mensen die er niet meer werken. Niet alle legacy code is slechte code. Maar in legacy code stapelt technische schuld zich vaak op: verouderde systemen, ontbrekende tests en documentatie die niemand meer bijhoudt.
Soorten technische schuld (technical debt)
Martin Fowler deelt technical debt in langs twee assen: bewust of onbewust, en verstandig of roekeloos. Dat geeft vier soorten:
| Verstandig | Roekeloos | |
|---|---|---|
| Bewust | “We leveren nu op en ruimen het daarna op.” | “We hebben geen tijd voor een goed ontwerp.” |
| Onbewust | “Nu pas zien we hoe het beter had gekund.” | “Wat is een goed ontwerp?” |
Naast deze indeling is het praktisch om te kijken wáár de schuld zit:
- Code: dubbele code, lange functies, onduidelijke namen, uitzonderingen die overal doorheen lopen.
- Architectuur: onderdelen die te sterk aan elkaar vastzitten, waardoor één wijziging overal impact heeft.
- Afhankelijkheden: een framework, PHP-versie of library die geen updates meer krijgt.
- Tests: lage code coverage of tests die niet meer draaien, zodat elke wijziging een risico is.
- Documentatie: kennis die alleen in hoofden zit.
- IT-infrastructuur: handmatige deploys, servers die niemand durft te updaten, geen monitoring of infrastructure as code. Verouderde systemen in de infrastructuur maken ook een overstap naar de cloud lastig.
Hoe ontstaat technische schuld?
Technische schuld ontstaat bijna nooit door één beslissing. Het is een optelsom:
- Deadlines waarbij “eerst werkend, later netjes” de afspraak was, maar later nooit kwam.
- Wisselende developers, elk met een eigen aanpak.
- Een applicatie die meegroeide met de bedrijfsprocessen, zonder dat de architectuur werd aangepast.
- Updates van frameworks en PHP die werden uitgesteld omdat alles nog werkte.
- De wereld verandert: wat vijf jaar geleden een goede keuze was, is nu verouderd.
Vooral dat laatste wordt onderschat. Ook goed gebouwde software krijgt technische schuld als je hem niet onderhoudt.
Hoe herken je technische schuld?
Je hoeft geen developer te zijn om technische schuld te herkennen. Let op deze signalen:
- Kleine wijzigingen duren steeds langer en worden steeds duurder.
- Na een update gaan onverwacht andere onderdelen stuk.
- Er is één persoon die “weet hoe het werkt”, en zonder die persoon ligt alles stil.
- De applicatie draait op een framework- of PHP-versie die geen security-updates meer krijgt.
- Niemand durft de oude code aan te raken.
- Nieuwe developers hebben weken nodig om de applicatie te begrijpen.
- Er zijn geen automatische tests, of ze worden overgeslagen.
Herken je drie of meer punten? Dan is het verstandig om de schuld in kaart te brengen voordat je grote nieuwe plannen maakt.
Wat kost technische schuld?
De kosten van technische schuld zijn grotendeels verborgen. Ze staan niet op een factuur, maar zitten in:
- Vertraging: ontwikkeltijd die opgaat aan omwegen in plaats van nieuwe functies.
- Fouten en storingen: bugs die terugkomen en incidenten die tijd en vertrouwen kosten.
- Beveiliging: verouderde onderdelen met bekende kwetsbaarheden.
- Afhankelijkheid: kennis die bij één ontwikkelaar of leverancier ligt.
- Gemiste kansen: systemen koppelen, schaalbaarheid, een overstap naar de cloud of andere innovatie die niet lukt omdat de basis het niet toelaat.
- Prestaties: een trage applicatie kost je gebruikers tijd en efficiëntie, elke dag weer.
Op een gegeven moment kan de schuld zo groot worden dat moderniseren of zelfs opnieuw bouwen een aanzienlijke investering vraagt. Het doel is om dat moment voor te zijn.
Technische schuld uitleggen aan het management
Voor het management is “de code is rommelig” geen reden om budget vrij te maken. Vertaal technische schuld daarom naar impact op de bedrijfsvoering: hoeveel langer duurt het om een nieuwe functie te implementeren, welke risico’s loop je op beveiliging, en wat zijn de grote gevolgen als dit onderdeel uitvalt? Zo wordt het aflossen van tech debt een normale prioriteit naast nieuwe functionaliteit, in plaats van een technisch hobbyproject van de ontwikkelaar.
Technische schuld aanpakken en verminderen in 5 stappen
1. Maak de schuld zichtbaar
Je kunt alleen prioriteren wat je ziet. Breng in kaart welke versies, afhankelijkheden, tests en risico’s er zijn. Een codebase scan doet precies dat: een onafhankelijke blik op de staat van de code.
2. Prioriteer op impact en risico
Niet alle schuld hoeft weg. Prioriteren doe je op twee vragen: hoe vaak verandert dit onderdeel, en wat gebeurt er als het misgaat? Schuld in een kritiek onderdeel dat vaak verandert, pak je als eerste aan. Schuld in code die je nooit aanraakt, kan blijven liggen.
3. Reserveer structureel tijd
Maak het aflossen van technische schuld onderdeel van je planning en roadmap. Bijvoorbeeld een vast deel van elke sprint of een vast aantal dagen per maand. Zo blijft het beheersbaar in plaats van een groot project.
4. Bouw een vangnet
Schrijf tests rond de belangrijkste processen voordat je oude code wijzigt. Met een geautomatiseerde workflow voor testing en deploy kun je daarna veilig refactoren en updaten.
5. Blijf technische schuld beheren
Voorkom nieuwe schuld: houd frameworks en PHP bij (lees hoe je een PHP upgrade aanpakt), leg bewuste keuzes vast en evalueer regelmatig. Zo blijft de schuld onder controle en blijft je software makkelijk te onderhouden en verder te ontwikkelen.
Technische schuld bij het overnemen van software
Neem je een applicatie over van een vertrekkende developer of een bureau dat stopt, dan neem je ook de technische schuld over. Breng die daarom vóór de overdracht in kaart. In onze checklist voor het overnemen van een applicatie lees je waar je verder op let.
Laat je technische schuld in kaart brengen
Wil je weten hoeveel technische schuld er in je software zit, wat de impact is en waar je moet beginnen? Met een codebase scan van je webapplicatie krijg je een helder rapport met de versies, de risico’s en een prioriteitenlijst die ook een niet-developer kan lezen. Zo beslis je op basis van feiten of je gaat onderhouden, upgraden of herbouwen.