Van Technical Debt naar duurzame software: legacy vraagt om eigenaarschap, visie en ruggengraat

Dit artikel is oorspronkelijk geschreven in het Engels.‍
‍

‍
Legacy is zelden alleen een technisch probleem

Iedereen die langer in de softwareontwikkeling meeloopt, kent het moment dat een systeem begint te haperen. Nieuwe functionaliteit toevoegen wordt steeds zwaarder, features veroorzaken bugs op onverwachte plekken en niemand durft bepaalde modules nog aan te raken. De term ‘legacy’ valt. Niet als technische definitie, maar als een collectief gevoel: we zitten vast.

In deze situaties zie je vaak een bekend patroon. Engineers zijn gefrustreerd en roepen al jaren dat het "eigenlijk helemaal opnieuw moet." De business ergert zich aan het technische geklaag ("waarom doen ze altijd zo moeilijk?") en op C-level heeft men vooral het gevoel de controle kwijt te zijn.

Wat volgt is een impasse. Iedereen heeft gelijk, maar er beweegt niets.

Het fundamentele probleem? We behandelen legacy te vaak als een technisch dossier, terwijl het in de kern een organisatorische uitdaging is. Technical debt klinkt technisch, maar de term 'debt' staat er niet voor niets. We hebben een lening afgesloten bij de toekomst en kunnen de rente niet meer betalen.

Dat is een financieel en strategisch probleem, geen puur technisch probleem.

Wat we ook vaak zien: de business onderschat haar eigen rol. Veel technical debt ontstaat niet door slecht programmeerwerk, maar door jarenlange functionele druk zonder de vraag: "Moet dit eigenlijk wel in het product?" Wat begon als een snelle uitzondering, zit nu vastgebakken in de codebase. Een optelsom van uitzonderingen zonder visie vormt geen strategie, maar chaos.

Aan de andere kant vinden engineers het vaak lastig om hun verhaal goed over te brengen. "We moeten opnieuw beginnen" is vaak het signaal, maar met decennia aan opgebouwde complexiteit is dat zelden realistisch. En al helemaal niet veilig.

De eerste stap bij elke legacy uitdaging gaat dus niet over code, maar over communicatie. Begrip. En de gedeelde acceptatie dat de situatie complex is en niet 1-2-3 is opgelost.

‍

Herpositionering en cultuurverandering: de twee paden naar herstel

Zodra teams beseffen dat legacy een gezamenlijke uitdaging is, ontstaat er ruimte. Ruimte voor actie, verdeeld over twee parallelle sporen: productherpositionering en cultuurverandering.

Herpositionering: terug naar de kern

In bijna elke legacy-case horen we dezelfde zin: "Het product is alle kanten op geschoten." Dat klopt meestal ook. Jarenlang "even snel dit" en "voeg dat ook maar toe" hebben het product uitgerekt tot iets wat niemand meer volledig doorgrondt.

Herstel begint daarom bij een scherpe herpositionering. Niet door alles dicht te timmeren, maar door samen opnieuw te definiëren waar het product eigenlijk voor dient. Wat is de kern? Op welke principes baseren we onze keuzes? Wat bouwen we wel, en belangrijker: wat bouwen we niet?

Dit is geen taak die alleen bij product management ligt. Een goede herpositionering ontstaat in dialoog met development, sales en support. Duurzame keuzes maken betekent namelijk ook: verwachtingen managen. Wat je klanten belooft, moet matchen met wat je kunt bouwen en onderhouden. Daar begint het gesprek.

"Zonder een gedeelde productvisie is elke roadmap een reactie op de waan van de dag."

Cultuurverandering: eigenaarschap herstellen

Minstens zo belangrijk, maar vaak lastiger, is het tweede spoor: het ontwikkelen van een andere engineering cultuur.

In legacy omgevingen zien we vaak teams die in een reactieve modus zitten. Features bouwen, bugs fixen, meters maken. Het lijkt productief, maar onder de motorkap loopt het systeem vast. Onderhoud wordt uitgesteld. Architectuur raakt uit balans. Niemand heeft de ruimte om na te denken over slimmere manieren van werken.

De sleutel is het herstellen van eigenaarschap. Niet alleen over de code, maar over de hele product-mindset. Dat betekent:

• Refactoring is iets wat je continu doet, niet als apart project.
• Technische keuzes houden rekening met de toekomst, niet alleen met het nu.
• Communicatie met stakeholders is geen bijzaak, maar een strategisch instrument.
  

Dit vraagt om nieuwe gewoontes: retrospectives met technische evaluaties, samen beslissen over design keuzes, reflectie op tooling en processen. Niet voor de controle, maar vanuit vakmanschap. Engineers moeten de ruimte voelen om te zeggen: "Dit kan beter," en het vervolgens ook echt beter maken.

Dat werkt alleen in een cultuur met psychologische veiligheid. Waar ruimte is voor twijfel, feedback en experimenten. Waar de focus niet alleen op de output ligt, maar ook op de manier waarop die output tot stand komt. Zonder die cultuuromslag blijf je aan de buitenkant poetsen terwijl het fundament langzaam verpulvert.

‍‍

Het echte werk begint met doorzettingsvermogen

Het goede nieuws: zodra deze twee sporen gaan lopen, komt dat gepaard met energie die vrij komt. Teams voelen zich sterker, het initiatief keert terug en de motivatie stijgt. De gesprekken tussen afdelingen worden constructiever. Er is weer perspectief.

Maar dat moment is fragiel. De druk komt namelijk altijd terug. Een klant dreigt weg te gaan. Een strategische roadmap krijgt voorrang. Iemand roept: "We hebben nu een oplossing nodig!" Voor je het weet, schiet iedereen terug op hun oude reflex. Focus weg. Balans weg. Terug naar de reactieve modus.

Daarom is volhouden misschien wel de belangrijkste stap, en tegelijkertijd de minst populaire.

Volhouden betekent je principes verdedigen. "Nee" zeggen tegen functionaliteit die het fundament ondermijnt. Blijven investeren in technische gezondheid, ook als het rendement op papier niet direct zichtbaar is. En het gesprek tussen tech, business en product gaande houden, juist als het schuurt.

Volhouden betekent ook: fouten durven maken. Dingen proberen die niet werken. En dan opnieuw kiezen. Reflecteren. Bijsturen. Niet omdat falen het doel is, maar omdat je pas leert als je bij de eerste tegenslag niet direct terugvalt in het oude model.

"Je valt terug. Je herstelt. Je gaat weer vooruit. Dat is geen falen, dat is verandering."

Uiteindelijk begint alles bij eigenaarschap. Niet als abstract concept, maar als dagelijkse praktijk. Teams die zich eigenaar voelen, maken betere keuzes. Bouwen met meer visie. Werken met meer plezier. En leveren uiteindelijk betere software.