Technical debt: waarom je software je organisatie afremt

Technical debt, in het Nederlands technische schuld, is het opgestapelde nadeel van eerdere keuzes in je software. Snelle oplossingen, uitgestelde updates en achterstallig onderhoud tellen op. Je betaalt de rekening in tijd: elke volgende wijziging kost meer dagen en meer geld dan de vorige.

Je herkent het aan het ritme. Een aanpassing die vorig jaar in twee dagen klaar was, staat nu drie weken op de planning. Er is één persoon die het systeem nog echt begrijpt. En bij elke vraag zegt je leverancier dat het “complex ligt”.

Dit artikel is voor de beslisser die vermoedt dat er iets mis is, maar het niet kan benoemen. Je krijgt een checklist, een rekensom en drie eerlijke routes eruit. Inclusief de route waarin je niets doet.

Technical debt is een metafoor uit de softwareontwikkeling. Net als bij een lening ga je nu sneller, en betaal je later rente. Die rente is geen geld, maar tijd: elke nieuwe wijziging kost meer moeite dan strikt nodig.

Er zijn twee soorten. Bewuste schuld ontstaat door een expliciete keuze: we bouwen dit tijdelijk simpel, want we moeten volgende maand live. Een legitieme afweging, mits je vastlegt wanneer je hem terugbetaalt. Onbewuste schuld ontstaat zonder dat iemand het merkt. Door verloop in het team, door een leverancier die het snel oploste, door frameworks die verouderden terwijl niemand keek.

Het verschil doet ertoe. Bewuste schuld is een besluit met een looptijd. Onbewuste schuld is een verrassing die pas opduikt als je iets wilt veranderen. In de praktijk is het meeste dat ik tegenkom onbewust.

Technische schuld is geen teken van slecht werk. Elk systeem dat lang genoeg meegaat bouwt het op. De vraag is niet of je het hebt, maar hoeveel en waar.

Je hebt geen developer nodig om technische schuld vast te stellen. De signalen zijn organisatorisch en zichtbaar vanaf je eigen bureau. Loop de checklist langs.

• Nieuwe functies kosten steeds meer tijd. Is dezelfde wijziging twee tot vier keer zo duur geworden, dan betaal je rente.
• Een kleine wijziging breekt iets elders. Onderdelen zijn dan te strak verweven.
• Er is één persoon die het systeem nog begrijpt. Dat is een enkel punt van falen.
• Updates worden uitgesteld omdat niemand durft. Een systeem dat je niet meer veilig kunt bijwerken is een risico. Ook juridisch.
• Nieuwe developers hebben maanden nodig. Vier tot zes weken is normaal. Zes maanden is een signaal.
• Je leverancier praat in risico’s in plaats van in oplossingen.
• Er is geen testomgeving of geautomatiseerde test. Elke wijziging gaat op gevoel live.
• Er draait software zonder ondersteuning van de leverancier. Een verouderde PHP-versie of een uitgefaseerd framework.

Vink je drie of meer punten aan, dan is technische schuld geen theoretisch risico maar een operationele kostenpost. Bij zes of meer is doorontwikkelen op de huidige basis meestal duurder dan de zwaarste onderdelen vervangen.

Legacy software is software die je niet meer veilig kunt veranderen. Dat is de enige bruikbare definitie. Leeftijd zegt weinig: een systeem uit 2014 dat netjes onderhouden is, is geen legacy. Een systeem uit 2022 waar niemand aan durft, is dat wel.

Legacy systemen hebben doorgaans drie kenmerken samen. De kennis erover is vertrokken. De technologie wordt niet meer ondersteund. En de documentatie bestaat uit de herinneringen van één collega.

Dat onderscheid bepaalt je route. Werkende software met achterstallig onderhoud ruim je op. Echte legacy vervang je stapsgewijs, want opruimen levert daar te weinig op tegenover het risico.

Let ook op een verwante afhankelijkheid: software die prima draait, maar op een platform waar je niet meer weg komt. Dat is geen technische schuld maar vendor lock-in, en het vraagt een andere oplossing.

Technische schuld kost zelden geld dat je op een factuur ziet staan. Het kost doorlooptijd, en doorlooptijd kost kansen. Reken het door.

Stel: een wijziging kostte drie jaar geleden twee ontwikkeldagen. Nu kost dezelfde wijziging er acht. Je doet er vijftien per jaar. Dat zijn 90 extra ontwikkeldagen. Tegen €900 per dag is dat €81.000 per jaar aan rente. Elk jaar opnieuw, en het loopt op.

Daar komen drie kosten bij die niet in uren te vangen zijn:

• Gemiste kansen. Een campagne die drie maanden wacht op een koppeling. Een klant die afhaakt omdat je een integratie niet kunt leveren.
• Risico. Verouderde componenten zijn een beveiligingslek in wording. Bij een datalek is achterstallig onderhoud geen excuus richting de Autoriteit Persoonsgegevens.
• Mensen. Goede developers vertrekken uit systemen waarin ze niets kunnen verbeteren. Dat versnelt het kennisverlies dat de schuld veroorzaakte.

Software kwaliteit is geen abstract begrip. Het is het verschil tussen twee en acht dagen voor dezelfde vraag. Hoe die dagprijzen zich verhouden tot nieuwbouw lees je in ons artikel over wat software ontwikkelen kost.

Er zijn drie routes. Welke past, hangt af van hoeveel het systeem nog moet veranderen en hoe groot het risico is.

Route 1: refactoren. Je ruimt de code stapsgewijs op zonder de functionaliteit te wijzigen. Voor de gebruiker verandert er niets, voor het team verandert alles. Dit loont als het systeem strategisch is en de kennis in huis is. Reken op 15 tot 20 procent van elke sprint.

Route 2: moderniseren of migreren. Je vervangt onderdelen in plaats van het geheel. De koppelingen eerst, dan de interface, dan de kern. Een software migratie in één keer is de duurste variant, en de enige waarbij je maanden zonder werkend systeem zit. Doe het stapsgewijs. Daarom beginnen wij klein en valideren we voordat we schalen.

Route 3: ermee leven. De route die je zelden hoort van een partij die het werk zou kunnen doen. Toch is het regelmatig het juiste antwoord. Niets doen is verdedigbaar bij drie voorwaarden: het systeem draait stabiel, er staan geen grote wijzigingen op de roadmap, en beveiligingsupdates kun je nog uitvoeren.

Zodra je geen security-updates meer kunt doorvoeren, vervalt “ermee leven” als optie. Dan is het geen kostenvraag meer, maar een risicovraag.

Een veelgemaakte fout: opnieuw bouwen omdat het systeem oud voelt. Dat is een dure emotie. Vervang alleen wat aantoonbaar remt, en meet dat aan doorlooptijd. Wat dat betekent voor maatwerk software hangt af van hoeveel logica je meeneemt.

Voordat je kiest, wil je weten waar de schuld zit. Een software audit brengt dat in kaart. Geen technisch rapport voor developers, maar een beslisdocument. Een bruikbare audit levert vier dingen op:

1. Waar de schuld zit. Meestal zit 80 procent van de pijn in 20 procent van het systeem.
2. Wat het risico is. Beveiliging, continuïteit en afhankelijkheid van personen, uitgedrukt in scenario’s.
3. Wat het kost om op te lossen. Per onderdeel, met een indicatie in weken en euro’s.
4. Wat het kost om niets te doen. De extra ontwikkeldagen per jaar, omgerekend naar euro’s op basis van jouw cijfers.

Een audit van een middelgroot systeem duurt één tot drie weken. Reken op €3.500 tot €9.000, afhankelijk van de omvang en de beschikbare documentatie. Klein ten opzichte van de bedragen waarover je daarna beslist.

Een IT audit kijkt breder: ook naar processen, licenties en governance. Voor de vraag “waarom gaat onze doorontwikkeling zo traag” is een gerichte software audit sneller en goedkoper.

Technische schuld voorkom je niet volledig. Beheersbaar houden kan wel. Drie keuzes maken bij nieuwbouw het verschil.

Kies een architectuur waarin onderdelen los van elkaar kunnen veranderen. Wat losgekoppeld is, vervang je later zonder het geheel te raken. Dat begint bij de software architectuur, niet bij de code. Zeker als je een digitaal platform bouwt dat jaren mee moet.

Bouw klein en itereer. Een systeem dat twee jaar in het donker wordt gebouwd, is bij livegang al verouderd. Werkende software in sprint 1, daarna uitbreiden op basis van gebruik.

Reserveer onderhoudstijd vanaf dag één. Geen aparte begroting die sneuvelt bij tegenwind, maar een vast deel van de capaciteit. Software die niet wordt onderhouden, wordt legacy. Dat is geen risico, dat is een planning.

Het onderliggende punt geldt bij elk digitaal project: innovatie is geen software, innovatie is adoptie. Een systeem dat niemand durft aan te raken, wordt niet doorontwikkeld. En wat niet doorontwikkelt, wordt niet gebruikt.