Een ontwikkelaar krijgt een verzoek dat eenvoudig klinkt: voeg één extra taal toe aan de website. De teksten zijn al vertaald. Toch blijkt de wijziging geen middag werk, maar een klus van meerdere dagen. Op verschillende plekken staan taalkeuzes vast in templates, foutmeldingen en koppelingen. Iedere aanpassing heeft onverwachte gevolgen.
Het probleem is niet dat de oorspronkelijke ontwikkelaars slecht werk leverden. Misschien moest de website destijds snel online en was één taal voldoende. Maar een ontwerpkeuze die toen tijd bespaarde, maakt nieuwe veranderingen nu duurder. Dit fictieve scenario laat zien waarom technical debt pas echt interessant wordt wanneer je de gevolgen zichtbaar maakt.
Technical debt is geen synoniem voor slechte code
De term technical debt is een metafoor: een technische keuze kan vandaag voordeel opleveren, terwijl je later extra inspanning nodig hebt om verder te ontwikkelen. Martin Fowler maakt daarbij twee onderscheidingen. Technische schuld kan bewust of onbewust ontstaan, en een keuze kan verstandig of roekeloos zijn. Ook een goed team kan achteraf ontdekken dat een ontwerp anders had gemoeten.
Dat betekent dat niet iedere snelle oplossing een fout is. Een startup die een beperkt product test, kan bewust kiezen voor eenvoudige templates en een latere uitbreiding. Als die keuze bekend is en de gevolgen acceptabel zijn, kan dat rationeel zijn. Het probleem ontstaat wanneer de concessie onzichtbaar wordt, gebruikers er steeds vaker last van krijgen of niemand nog weet waarom iets zo is gebouwd.
De rekening verschijnt bij de volgende wijziging
Terug naar onze website. Bij de eerste release was er één taal en één team. Later komen vertalingen en externe editors erbij. Het team ontdekt dat foutmeldingen niet worden vertaald, dat componenten verschillende oplossingen voor dezelfde taalinstelling gebruiken en dat regressietests ontbreken.
De kosten van deze technical debt zitten niet alleen in de refactor zelf. Ook elke tussentijdse wijziging vergt extra controles, overleg en herstelwerk. Om de schuld te prioriteren, helpt het daarom weinig om in de backlog uitsluitend ‘oude code opruimen’ te zetten.
Leg liever vast welk concreet effect de beperking heeft. Welke nieuwe functionaliteit duurt langer? Welke fouten komen terug? Welke systemen of gebruikers worden geraakt? Wat gebeurt er wanneer het volume stijgt of een leverancier verandert? Zo wordt technical debt een product- en beheervraagstuk in plaats van een abstract technisch bezwaar.
Leg de reden vast voordat die vergeten wordt
Een kort Architecture Decision Record (ADR) helpt om belangrijke ontwerpbesluiten te bewaren. Noteer de context, alternatieven, gekozen oplossing, redenen en gevolgen. Voeg voor bewust tijdelijke keuzes een eigenaar en herbeoordelingsmoment toe. ADR’s zijn bedoeld om te begrijpen waarom een architectuurkeuze ooit is gemaakt, niet om de beslissing achteraf automatisch goed te praten.
In ons scenario kan het oorspronkelijke besluit bijvoorbeeld zijn geweest: ‘Bij de eerste release ondersteunen we uitsluitend Nederlands, omdat er nog geen andere markten zijn. Bij uitbreiding naar een tweede taal vervangen we de hardcoded teksten door een centrale vertaalstructuur.’ Dat is een illustratief besluit, geen bestaand projectdocument.
Het verschil is groot. Wanneer een volgende ontwikkelaar ontdekt dat een ontwerp moeilijk uit te breiden is, hoeft die niet opnieuw te raden wat het team destijds bedoelde. De organisatie kan de oorspronkelijke afweging toetsen aan de nieuwe situatie.
Niet iedere schuld moet onmiddellijk worden afgelost
Er is een reden waarom de schuldenmetafoor nuttig blijft: je moet niet alleen kijken naar het bedrag dat herstel kost, maar ook naar de ‘rente’ die de beperking bij toekomstige wijzigingen veroorzaakt. Fowler beschrijft dat een technisch minder ideaal onderdeel soms prima kan blijven bestaan wanneer het zelden wordt aangepast en nauwelijks problemen veroorzaakt.
De prioriteit verschilt daarom per situatie. Een niet-ondersteunde runtime met relevante beveiligingsrisico’s vraagt om een andere reactie dan een oude, stabiele interne module waar niemand aankomt. Een handmatig releaseproces dat iedere week fouten veroorzaakt kan juist sneller waarde opleveren als je het automatiseert.
Gebruik daarbij niet alleen een technische ernstscore. Beoordeel hoe vaak een onderdeel verandert, hoeveel tijd het huidige ontwerp kost, welke incidenten het veroorzaakt en wat het risico van ingrijpen is. Een volledige herbouw is zelden de enige optie: soms volstaan een afgebakende refactor, een test of het isoleren van een kwetsbaar grensvlak.
Begin bij de plekken waar fouten doorwerken
Bij integraties en API’s zitten belangrijke risico’s vaak in authenticatie, foutafhandeling, contractwijzigingen en herhaalde verzoeken. Een koppeling kan bijvoorbeeld goed werken zolang alles bereikbaar is, maar vastlopen wanneer een externe API tijdelijk niet reageert. Ontbreken retries, idempotentie of voldoende monitoring, dan kan een kleine storing grotere gevolgen krijgen.
Het is daarom verstandig om kritieke gebruikersroutes en foutscenario’s eerst reproduceerbaar te maken. Test bijvoorbeeld wat er gebeurt als een afhankelijkheid tijdelijk uitvalt of dezelfde opdracht opnieuw wordt verstuurd. Een hoog code-coveragepercentage zegt op zichzelf weinig over de kwaliteit van die specifieke foutafhandeling.
Onze sponsor BlazeForce bespreekt vergelijkbare ontwerprisico’s in een artikel over integratiefouten bij groeiende organisaties. Dat is een praktische verdieping, geen reden om iedere bestaande koppeling preventief te herbouwen.
Van frustratie naar een toetsbaar verbeterbesluit
Voor ons meertalige websitevoorbeeld kan het team de beperking nu concreet beschrijven: een extra taal vereist aanpassingen in meerdere templates en verhoogt de kans op vergeten vertalingen. Het doel is dan niet ‘de code mooier maken’, maar bijvoorbeeld: ‘Nieuwe vertalingen kunnen worden toegevoegd zonder wijzigingen aan presentatiecomponenten, en ontbrekende vertalingen krijgen een gedocumenteerde fallback.’
Leg vervolgens vast wie de verbetering uitvoert, wanneer deze opnieuw wordt beoordeeld en hoe je het resultaat controleert. Meet na de wijziging of het toevoegen van een taal inderdaad eenvoudiger is geworden. Zonder die laatste controle weet je nog steeds niet of de technische investering werkelijk waarde heeft geleverd.
Meer van dit soort ontwerpafwegingen staan in het Dogteam-kennisdossier webarchitectuur.
De echte schuld is dat niemand de gevolgen nog kent
Technical debt verdwijnt nooit volledig uit softwareontwikkeling. Teams leren onderweg, eisen veranderen en oplossingen die ooit goed pasten kunnen verouderen. Het doel is daarom niet alle concessies uit te bannen.
Het doel is zichtbaar te houden welke concessies zijn gemaakt, wat ze kosten en wanneer herstel meer oplevert dan uitstel. Zodra ontwikkelaars, product owners en beheerders daar samen over kunnen beslissen, verandert technical debt van een vaag kwaliteitsprobleem in een beheersbare architectuurkeuze.
Bronnen
- Martin Fowler — Technical Debt Quadrant (2009)
- Architectural Decision Records — definities en praktijk
Neem contact met ons op
Vertel ons waarmee we kunnen helpen; we reageren binnen twee werkdagen.
