Technische schuld: waarom snelle software vandaag morgen duur kan uitpakken
Stel je voor dat je een dakkapel laat bouwen, maar de aannemer heeft geen tijd om het dak goed te isoleren. Hij belooft: "Dat maken we later wel af." Het dak is sneller klaar en je bespaart nu geld, maar over een paar jaar tocht het, lekt het misschien, en moet je alsnog een dure verbouwing laten uitvoeren — vaak duurder dan wanneer het meteen goed was gedaan. Iets vergelijkbaars gebeurt voortdurend in de wereld van software, en programmeurs noemen dat verschijnsel technische schuld (Engels: technical debt).
Technische schuld ontstaat wanneer ontwikkelaars bewust of onbewust een snellere, minder zorgvuldige manier kiezen om software te bouwen, met de bedoeling dat later recht te zetten. Net als bij een lening op de bank betaal je daar "rente" over: elke keer dat iemand die haastig geschreven code moet aanpassen, kost dat meer tijd en moeite dan wanneer het meteen netjes was gedaan. Blijft die schuld te lang onbetaald, dan stapelt de rente zich op totdat een programma traag, onbetrouwbaar of zelfs onwerkbaar wordt.
Wat is het precies?
Software bestaat uit miljoenen regels code die door mensen worden geschreven, gelezen en aangepast. Elke keuze die een ontwikkelaar maakt — hoe een functie is opgebouwd, of er tests zijn geschreven, of de documentatie klopt — beïnvloedt hoe makkelijk die code later te onderhouden is. Technische schuld ontstaat op verschillende manieren.
Soms is het een bewuste keuze: een team kiest ervoor om een deadline te halen door een eenvoudige, niet-ideale oplossing te bouwen, met het plan om die later te verbeteren. Softwarearchitect Martin Fowler noemt dit "prudent" (verstandige) schuld, omdat het team weet wat het doet en waarom. Daartegenover staat "roekeloze" schuld: haastwerk zonder plan, vaak veroorzaakt door tijdsdruk of onervarenheid.
Schuld kan ook onbedoeld ontstaan. Programmeertalen, bibliotheken (herbruikbare stukjes code van anderen) en frameworks veranderen voortdurend. Code die vandaag prima werkt, kan over vijf jaar "verouderd" zijn omdat de onderliggende technologie niet meer wordt onderhouden. Ook groeiend inzicht speelt mee: een team ontdekt pas na verloop van tijd dat een bepaalde opzet niet goed schaalt, terwijl dat bij het schrijven ervan nog niet duidelijk was.
De "rente" op technische schuld uit zich concreet: bugs die moeilijker te vinden zijn, nieuwe functies die langer duren om te bouwen omdat ontwikkelaars eerst door verouderde of rommelige code heen moeten worstelen, en een groter risico op storingen. Het tegenovergestelde van schuld opbouwen is refactoren: code herstructureren zonder de werking ervan te veranderen, om ze weer overzichtelijk en onderhoudbaar te maken.
Wat wil men ermee bereiken?
Het doel van het benoemen van technische schuld is niet om haast of shortcuts te verbieden — die zijn soms nodig en zelfs verstandig. Het doel is om de afweging zichtbaar te maken. Een team dat weet dat het schuld aangaat, kan bewust kiezen: nu snel leveren en later tijd inplannen om het recht te zetten, in plaats van blind door te bouwen tot alles vastloopt.
Bedrijven willen technische schuld daarom meetbaar maken, bijvoorbeeld met tools die automatisch code doorlichten op duplicatie, complexiteit, verouderde onderdelen en ontbrekende tests. Zo kan een organisatie een deel van haar ontwikkelcapaciteit reserveren voor het "aflossen" van schuld, net zoals je maandelijks een lening aflost, in plaats van alleen aan nieuwe functies te werken.
Op de achtergrond speelt ook een bedrijfseconomisch belang: onopgeloste technische schuld leidt tot tragere productontwikkeling, hogere onderhoudskosten en een groter risico op grote storingen die klanten en reputatie schaden. Het beheersen van technische schuld is dus uiteindelijk een manier om softwarebedrijven op lange termijn wendbaar en betrouwbaar te houden.
Voorbeelden uit de praktijk
Een van de bekendste voorbeelden is Knight Capital Group, een Amerikaans handelsbedrijf. Op 1 augustus 2012 activeerde een nieuwe softwarerelease per ongeluk een oud, al jaren ongebruikt stuk testcode dat nooit was verwijderd. Binnen ongeveer 45 minuten voerde het systeem duizenden ongewenste beurstransacties uit, wat het bedrijf zo'n 440 miljoen dollar kostte en bijna tot een faillissement leidde. Het incident wordt in de sector veelvuldig aangehaald als schoolvoorbeeld van hoe opgestapelde, nooit opgeruimde code jarenlang sluimerend gevaar kan opleveren.
Bij Southwest Airlines zorgde eind december 2022 een grote winterstorm voor een kettingreactie: het verouderde systeem voor het inplannen van bemanningen kon de golf aan omboekingen niet aan, waardoor duizenden vluchten werden geschrapt en reizigers dagenlang vastzaten. In de berichtgeving en bij latere Congreshoorzittingen kwam naar voren dat de maatschappij al jaren kampte met verouderde IT-systemen die onvoldoende waren gemoderniseerd.
Ook grote techbedrijven ontkomen er niet aan. Twitter (nu X) kreeg na de overname door Elon Musk eind 2022 te maken met publieke discussies over de staat van zijn interne systemen, nadat een groot deel van het technische personeel was vertrokken of ontslagen, wat het onderhoud van bestaande code bemoeilijkte.
Overheidsinstanties lopen eveneens tegen technische schuld aan. In verschillende landen, waaronder Nederland, draaien belangrijke overheidssystemen (bijvoorbeeld bij de belastingdienst) nog gedeeltelijk op decennia oude programmeertalen zoals COBOL, waarvoor steeds minder ervaren programmeurs te vinden zijn — een directe vorm van opgebouwde technische schuld die vervanging kostbaar en risicovol maakt.
Hoe ver is de techniek?
Technische schuld is geen technologie die "af" kan zijn; het is een blijvend beheersvraagstuk zolang er software wordt geschreven. Wel is de manier waarop de sector ermee omgaat de afgelopen twintig jaar volwassener geworden. Er bestaan inmiddels geautomatiseerde tools (zogeheten statische code-analyse) die continu code doorlichten en signaleren waar risico's zitten, zodat teams niet alleen op onderbuikgevoel hoeven te vertrouwen.
Toch blijft het lastig om technische schuld in harde getallen of euro's uit te drukken. Verschillende meetmethoden geven verschillende uitkomsten, en niet elk risico is even goed te kwantificeren. Bedrijven gebruiken daarom vaak een combinatie van geautomatiseerde metingen en het ervaringsoordeel van ervaren ontwikkelaars.
Een actueel en nog onzeker vraagstuk is de opkomst van AI-codeerassistenten zoals GitHub Copilot en vergelijkbare tools, die sinds 2022-2023 in hoog tempo worden gebruikt. Onderzoekers en analisten wijzen erop dat dergelijke tools ontwikkelaars weliswaar sneller code laten schrijven, maar mogelijk ook leiden tot meer gedupliceerde of oppervlakkig gecontroleerde code — kortom, mogelijk nieuwe technische schuld, sneller dan voorheen. Hoe groot dit effect precies is en of het op lange termijn per saldo voor- of nadelig uitpakt, is nog volop onderwerp van discussie en onderzoek; harde, onafhankelijk herhaalde cijfers ontbreken vooralsnog.
Wie werken eraan?
De term technische schuld werd in 1992 geïntroduceerd door de Amerikaanse softwareontwikkelaar Ward Cunningham, die de vergelijking met financiële schuld gebruikte om aan niet-technische collega's uit te leggen waarom haastig geschreven code later tijd kost. Cunningham geldt sindsdien als de grondlegger van het begrip binnen de softwarewereld.
Op onderzoeksvlak houdt het Software Engineering Institute (SEI) van Carnegie Mellon University zich structureel bezig met het beheersen van technische schuld, onder meer via onderzoekspublicaties en de terugkerende internationale workshop "Managing Technical Debt", waar wetenschappers en industrie ervaringen uitwisselen.
Commercieel bieden bedrijven als SonarSource (bekend van het populaire analyseplatform SonarQube) en het Franse CAST Software tools aan die technische schuld in bestaande bedrijfssoftware in kaart brengen en proberen te kwantificeren, onder meer voor grote banken, verzekeraars en overheidsorganisaties. Daarnaast besteden vrijwel alle grote softwarebedrijven — van Google en Microsoft tot Nederlandse organisaties als banken en overheidsdiensten — intern aandacht aan het beheersbaar houden van hun codebases, al verschilt de mate waarin dit structureel wordt aangepakt sterk per organisatie.