Wanneer we de term technical debt horen, denken we vaak meteen aan een ontwikkelaar die slordig te werk gaat: een functie haastig afwerken, tests overslaan of overal ‘TODO’-opmerkingen achterlaten. Maar deze visie is zowel beperkt als schadelijk. Technical debt is niet alleen een rommeltje dat door een ontwikkelaar moet worden opgeruimd. Het is een teamprobleem en, nog belangrijker, een bedrijfsprobleem.

Wat is technical debt eigenlijk?
Technical debt verwijst naar de kosten van het kiezen van een gemakkelijke of snelle oplossing in plaats van een betere aanpak die misschien meer tijd kost. Net als financiële schuld brengt het rente op: hoe langer het onbetaald blijft, hoe meer het toekomstige ontwikkeling vertraagt, bugs introduceert en onderhoud bemoeilijkt.
Maar in tegenstelling tot persoonlijke creditcardrekeningen wordt technical debt zelden door één ontwikkelaar alleen gecreëerd. Het is vaak het resultaat van collectieve beslissingen.
De onderliggende oorzaken zijn vaak te vinden bij het team
Hier volgen enkele voorbeelden waarbij technical debt voortkomt uit team- of organisatiedynamiek:
- Haastige deadlines: stakeholders willen dat een bepaalde functionaliteit zo snel mogelijk wordt gelanceerd om het momentum in de markt te grijpen. Ontwikkelaars worden onder druk gezet om toegevingen te doen wat betreft de kwaliteit van de code om de deadline te halen.
- Gebrek aan documentatie of gedeelde standaarden: teams zonder duidelijke architecturale richtlijnen of code-conventies creëren gefragmenteerde codebases.
- Een “deferred maintenance” cultuur: product- en managementteams geven voorrang aan nieuwe functionaliteiten boven technische verbeteringen.
- Gescheiden teams: als teams die aan afzonderlijke onderdelen van een product werken niet op elkaar zijn afgestemd, stapelen slechte integratiekeuzes zich op en ontstaan er wrijvingen.
Er is ook vaak een communicatieprobleem tussen “technische mensen” (bvb. engineering) en “niet-technische mensen” (bvb. business): technische mensen moeten in zakelijke termen kunnen uitleggen waarom het aanpakken van technical debt. Mensen met een business achtergrond moeten kunnen begrijpen hoe het product op de lange termijn profiteert van het aanpakken van technische schuld.
Wanneer we het als een team issue beschouwen, creëren we ruimte voor langetermijndenken, slimmere trade-offs en uiteindelijk betere producten. Laten we ophouden met elkaar de schuld te geven en beginnen met het verbeteren van systemen.
Tot slot, voor de meerwaardezoeker: bekijk zeker dit artikel van dr. Milan Milanović, waarin hij het fenomeen “technical debt” op een bijzonder toegankelijke en illustratieve manier beschrijft. Een aanrader!