Technische schuld kost geld: hoe je het herkent bij je software team

· 10 min read

Wanneer heb jij voor het laatst een nieuwe functionaliteit opgeleverd gekregen, zonder dat er eerst drie andere dingen moesten worden gerepareerd of preventief gewijzigd? Als je even moet nadenken, is dat antwoord al veelzeggend. Technische schuld is stil, sluipend en duur. En het ergste eraan? Dat je er zo aan went dat je het niet meer ziet of door hebt. In dit artikel leer je waar je op moet letten, zelfs als je zelf geen ontwikkelaar bent.

Wanneer stilstand de nieuwe standaard wordt

Veel softwareproducten hebben een geschiedenis. Ze zijn ooit gebouwd door een toegewijd team, gegroeid met de organisatie, en uitgebreid naarmate de business dat vroeg. Op papier draaien ze prima. Maar onder de oppervlakte vertelt de code vaak een ander verhaal.

Dit is de wereld waar een consultant regelmatig instapt.

De organisaties die we tegenkomen hebben doorgaans een langlopend softwareproduct, regelmatig meer dan tien jaar oud, dat wordt beheerd door een intern of extern ontwikkelteam. Dat team heeft het product door de jaren heen laten groeien, kent het door en door, en is er volledig op ingesteld. Op het eerste gezicht lijkt dat een kracht. En dat was het ook, ooit...

Maar de technische wereld staat niet stil. Frameworks evolueren. Deployment-praktijken veranderen. Wat in 2016 een moderne aanpak was, is in 2026 achterhaald. De teams die we aantreffen hebben die ontwikkeling grotendeels gemist. Niet uit onwil, maar omdat ze zich comfortabel hebben gevestigd in wat ze kennen. Ze hebben in die zin hun technische piek bereikt, en zijn daar gebleven.

Het gevolg is vaak een omgeving die functioneert, maar nauwelijks meer beweegt.
En als je ernaar vraagt, is het antwoord dat iedereen inmiddels heeft geaccepteerd: "Dit is gewoon hoe het werkt. Dit is de realiteit van dit systeem."

Dat zinnetje is de aanleiding voor alles wat volgt.

Want wat als die realiteit helemaal niet zo vast staat als iedereen denkt? Wat als de vertraging geen eigenschap is van het product, maar een symptoom van iets wat te veranderen valt?

Precies die vraag brengt een consultant in beeld.

Probleem: "Dit is gewoon hoe het werkt"

Elke change duurt minstens een week voor het online staat. Releases zijn spannende momenten in plaats van routineklussen. Nieuwe functionaliteiten worden steeds vaker uitgesteld ten gunste van fixes op wat al bestaat.

En als je ernaar vraagt, is het antwoord steevast hetzelfde: "Dit is gewoon hoe het werkt. Dit is de realiteit van dit systeem."

Dat zinnetje is het gevaarlijkste in de hele situatie. Want het normaliseert iets wat niet normaal is. Het maakt van een structureel probleem een geaccepteerde omgeving. En ondertussen wordt de stroop alleen maar dikker.

Wat je aantreft als je de motorkap echt optilt:

  • Geen of minimale testdekking. Niemand weet zeker of een wijziging iets breekt, dus iedereen is voorzichtig en angstig voor veranderingen. Die voorzichtigheid kost veel tijd en momentum.
  • Geen geautomatiseerde CI/CD. Releases zijn spannend, vaak handmatig, risicovol en nog het aller ergste: afhankelijk van specifieke mensen op specifieke momenten.
  • Amper documentatie. Kennis zit in hoofden, niet in systemen. Onboarding, systeemplaten, worden snel gezien als 'overbodig'. Iedereen heeft toch altijd precies dezelfde interpretatie van een bepaald domein en ieder proces?
  • Een Brent. Iedereen die The Phoenix Project heeft gelezen kent hem: de ene developer die alles weet, alles kan, en zonder wie niets kan worden opgeleverd. Hij is geen held. Hij is een 'single point of failure' dat het hele systeem gijzelt. De personifactie van dat luikje in de Death-Star.

En dan is er nog de werkvoorraad. Als je die analyseert, zie je het patroon meteen: meer fixes dan nieuwe functionaliteiten. Het team repareert constant wat al bestaat, en komt niet meer toe aan het leveren van nieuwe waarde.

Aanpak: meenemen, niet confronteren

Wanneer je als consultant aankaart dat er iets structureel mis is, stuit je bijna altijd op weerstand. "Onze mensen zijn toch goed? Ze zijn betrokken, ze werken hard."

Dat klopt ook. Maar stilstand is achteruitgang in de tech-wereld. Hard werken en efficient werken zijn twee verschillende dingen, dat geld ook voor "goed zijn" en "goed blijven" als ontwikkelaar.

De aanpak die goed werkt is er een van mensen meenemen, en positief confronteren. Je behandelt de domeinkennis van het bestaande team als het waardevolle bezit dat het is. Zij kennen het product, de klant, de edge cases. Jij brengt technische vernieuwing mee en een lik van buitenaf. Die ruil werkt alleen als er wederzijds respect is.

In de praktijk betekent dit:

Stap 1 — Rand-organisatie op orde.Scrum-events, een werkbord dat iedereen gebruikt, duidelijke werkvoorraad bepaling. Hier geldt één ijzeren wet: ShiSho (Shit-in-Shit-out). Een vage werkvoorraad levert vage oplossingen. Goede werkvoorraad bepaling onthult ook meteen de technische achterstalligheden. Die komen als eerste bovendrijven. Dat is vaak ook een grote blokker. "We moeten nog zoveel oplossen voor we weer 'echte' waarde kunnen leveren!" - en dat klopt.

Stap 2 — Technische hygiëne herstellen.CI/CD opzetten, testdekking opbouwen, deployment-afspraken maken. Niet als doel op zich, maar als fundament voor alles wat daarna komt. Dit is ook het moment om het team mee te nemen in wat er tegenwoordig mogelijk is. Niet als kritiek op wat ze deden, maar als opening naar wat ze kunnen worden. Dit versnelt het algehele software- en waarde- leveren proces ook. Zo is de grote blokker van Stap 1 ook sneller opgelost.

Stap 3 — Architectuur heroverwegen waar nodig.Dit blijft vaak relatief beperkt bij bestaande teams, maar het gesprek moet wel gevoerd worden. Wordt er iets nieuws gebouwd? Dan wil je daar altijd iets over te zeggen hebben als consultant, zodat het op moderne manieren gebeurt, niet op de manieren van tien jaar geleden. Pleister-oplossingen moeten niet meer geaccepteerd worden. Dat is hoe het team in eerste instantie achter is gaan lopen op hun doelen.

Oplossing: van fixes naar waarde

De verschuiving die je wilt zien, gaat van een werkvoorraad vol achterstalligheden naar een werkvoorraad die gedreven wordt door domein en business; nieuwe waarde voor de gebruiker creeeren.

Die verschuiving kost tijd. Reken op enkele maanden voor merkbare technische verbeteringen: betere CI/CD, testdekking, zekerheid over kwaliteit. Reken op een jaar voordat het team structureel nieuwe functionaliteiten levert en gewend is aan het noodzakelijke refinen van werk-items. Het spijt me, als je dacht dat je jaren van achterstallig onderhoud kon oplossen in een paar maanden. Dat is helaas niet zo.

Wat je niet moet doen, is je blindstaren op tooling-scores. Denk aan SonarQube, Sigrid en testdekking in percentages. Deze vertellen een deel van het verhaal, maar niet het hele verhaal. Het gaat uiteindelijk om vragen als: is dit product toekomstbestendig? Is het modern? Kan het de groei aan van gebruikers/features?

Dat zijn technische, complexe en toch soms subjectieve vragen. Maar het zijn wel de juiste.

Immers kan je 100% test-coverage hebben, de perfecte SonarQube en Sigrid scores hebben en toch het verkeerde systeem hebben gebouwd. Oepsie!

Lessons learned: wat elke opdrachtgever zou moeten weten

Je hoeft geen technische achtergrond te hebben om technische schuld te herkennen. Dit zijn de signalen:

Je werkvoorraad gaat meer over fixes dan over nieuwe functionaliteiten. Als het grootste deel van wat je team doet bestaat uit het repareren van dingen die al bestaan, betaal je veel rente op technische schuld.

Je hebt een "Brent". Één persoon zonder wie alles stilstaat is geen troef, het is een risico. En een teken dat kennis niet is geborgd in het team.

Je team wijst altijd naar bepaalde personen. Niet omdat deze persoon de enige is die iets kan, maar omdat hij of zij drie jaar geleden dat ene systeem heeft gebouwd en sindsdien is die kennis nooit overgedragen. Iedereen weet wie je moet hebben, maar niemand weet wat diegene eigenlijk weet. Dat is geen samenwerking, dat is een tikkende tijdbom.

Je ontwikkelaars praten nooit over nieuwe versies of releases. Technologie staat nooit stil, en een team dat bijblijft, volgt actief de releasekalenders van de platformen waarop ze bouwen. Dat geldt voor élke stack: van een Microsoft-georiënteerd team verwacht je elk jaar een .NET-upgrade te zien in de werkvoorraad. Ook een Java-team hoort de overstap naar een nieuwe LTS-versie te plannen. Een frontend-team hoort te weten welke versie van hun framework actueel is. Het specifieke platform maakt niet uit, het patroon wel. Als dat gesprek nooit plaatsvindt, is dat een signaal dat het team niet langer meekijkt naar wat er buiten hun eigen systeem gebeurt.

Het grootste risico is niet dat je team slecht is of niet 'wil'. Het is dat niemand door heeft dat ze achterlopen.

Technische schuld bouwt zich niet op in één sprint. Het sluipt erin, over maanden en jaren. Elk kwartaal dat een framework-upgrade wordt uitgesteld, elke feature die zonder tests wordt opgeleverd, elke Brent die iets bouwt zonder het over te dragen of goed te documenteren, het zijn kleine stappen. Afzonderlijk nauwelijks merkbaar. Samen vormen ze een rem die zo geleidelijk wordt ingedrukt dat niemand het moment kan aanwijzen waarop het fout ging.

Dat is precies waarom het zo moeilijk te spotten is van binnenuit. Je went aan het tempo. Je accepteert de doorlooptijden. En op het moment dat je je afvraagt waarom alles zo lang duurt, is de rem al jaren langzaam ingedrukt. En er is niet een iemand die dat bewust heeft laten gebeuren.

Conclusie: sta je bijna stil, of beweeg je vooruit?

Wat deze trajecten keer op keer laten zien, is dat technische schuld zelden ontstaat door slechte intenties. Teams stagneren omdat ze comfortabel zijn geworden in wat werkt, en omdat niemand van buitenaf vraagt wat er eigenlijk nog meer mogelijk is. De rem wordt zo langzaam ingedrukt dat niemand het voelt. Iedereen went aan het tempo, accepteert de doorlooptijden, en op het moment dat je je afvraagt waarom alles zo traag gaat, is de schuld al jaren opgebouwd. De oplossing blijkt vaak niet het vervangen van mensen of systemen, maar het structureren van de werkwijze, het herstellen van technische hygiëne en het meenemen van het bestaande team in een nieuwe manier van werken.

Technische schuld is geen technisch probleem. Het is een bedrijfsprobleem dat zich opbouwt over jaren, in kleine stappen, zonder dat iemand een bewust besluit neemt om achter te blijven.

Herken je dit? Je werkvoorraad staat vol fixes, kleine changes duren weken, er is één persoon zonder wie alles stilstaat en nieuwe functionaliteiten komen er maar niet van? Dan is het tijd om de vraag te stellen: "Hebben wij begeleiding nodig met het wegwerken van onze technische schuld?" Hoe langer die vraag onbesproken blijft, hoe dieper de schuld kan ingroeien. Een team dat stilstaat hoeft niet vervangen te worden. Het moet weer tractie krijgen door begeleiding, een duidelijke werkwijze, en de ruimte om te leren wat er tegenwoordig mogelijk is. Dat is geen overbodige luxe. Dat is onderhoud aan je belangrijkste digitale assets.

Neem contact op

Sta je voor dezelfde uitdaging? Deze consultant hoort graag hoe het bij jou speelt. Neem contact op en laten we het gesprek starten.