We wilden ooit iets simpels doen. Een paar schermen aanpassen zodat adviseurs en klanten sneller gegevens konden invoeren. Klein klusje toch? Dachten we. Tot we ontdekten dat er zoveel afhankelijkheden waren dat het ineens een project van maanden werd. En toen was het momentum weg. En het budget ook. Uiteindelijk kwam het er niet van. Te duur. Te complex. En eigenlijk te pijnlijk om te erkennen dat dit allemaal kwam door oude keuzes.
Welkom in de wereld van technical debt.
Oude systemen, oude pijn
De verzekeringsbranche werkt – laten we eerlijk zijn – nog veel met systemen die hun beste tijd wel hebben gehad. Mainframes, dikke koppelingen, half gedocumenteerde API’s, en een structuur die als je er lang naar kijkt verdacht veel weg heeft van een spaghetti western. Soms romantisch, meestal frustrerend.
Toch is het onvermijdelijk. Tenzij je alles opnieuw kunt bouwen én de hele organisatie meekrijgt (dat lukt niet, of er moeten hele strakke keuzes gemaakt worden), zit je met legacy. En dat is oké. Totdat je wendbaar wilt zijn. Snel iets wilt aanpassen. Iets wilt testen. Dan komt die technical debt als een boemerang terug.
Snijverlies en innovatiefrustratie
Wat vaak vergeten wordt: die achterstallige onderhoudstaken – hoe saai ze soms ook lijken – zijn essentieel voor je toekomstige slagkracht. Als je je architectural runway niet onderhoudt, loop je niet alleen risico, je vertraagt ook je innovatie. Je ontwikkelt minder snel, minder effectief, en soms… gewoon helemaal niet.
En dan komt de frustratie. Vanuit de business (“Waarom kan dit niet gewoon?”), vanuit IT (“Omdat het vastzit aan vijf andere dingen die ooit bedacht zijn toen Agile nog een shampoo was”), en vanuit de architectuur (“Had je toen maar even naar ons geluisterd…”).
Tijd om het beest in de bek te kijken
Technical debt oplossen is geen sexy werk. Het is niet iets waar je direct punten mee scoort op de roadmap. Maar het is broodnodig. Zie het als het vervangen van de fundering van een huis terwijl de bewoners binnen Netflixen. Niemand wil het, tot het dak ineens scheef hangt.
Wil je wendbaar zijn, compliant blijven en je mensen een beetje werkplezier gunnen? Dan moet er tijd, ruimte en vooral structuur komen om aan die fundering te werken. Iteratief. Ingepland. En met oog voor wat het je oplevert aan toekomstige snelheid.
Een pleidooi voor lef, balans en vooruitkijken
Technical debt los je niet in één keer op, maar je kunt er wél mee leren leven. Door het te benoemen. Door keuzes te maken. Door naast elke sprint voor nieuwe functionaliteit óók iets te doen aan je technische achterstalligheid. En ja, dat betekent dat je af en toe iets minder op je roadmap zet – om het tempo op de langere termijn juist op peil te houden.
Dus: kijk eens eerlijk naar je backlog. Hoeveel staat daar wat eigenlijk geen functioneel nut heeft, maar wel zorgt dat je straks sneller vooruit kunt? En hoe vaak schuif je dat naar achteren?
Technical debt is geen teken van falen. Het is het gevolg van keuzes die ooit logisch leken. Maar het negeren ervan… dat is pas echt risicovol.