Software die jarenlang trouw dienst doet, wordt ongemerkt lastiger te onderhouden. Elke wijziging duurt langer, updates worden uitgesteld en niemand durft nog aan bepaalde onderdelen te komen. Dan komt de vraag: investeren in wat er staat of opnieuw beginnen? In dit artikel lees je hoe je technische schuld herkent, hoe je de kosten van uitstel zichtbaar maakt en welke drie routes je hebt. Inclusief de manier waarop je een herbouw uitvoert zonder je bedrijf stil te leggen.
Wat technische schuld eigenlijk is
Technische schuld is geen scheldwoord voor slecht werk. Het is de opgetelde rekening van keuzes die op hun moment logisch waren: een snelle oplossing om een deadline te halen, een koppeling die "voorlopig" hard is ingeregeld, een framework dat destijds de standaard was. Net als bij een financiële schuld betaal je rente. Die rente is de extra tijd die elke nieuwe wijziging kost.
Een beetje schuld is gezond en soms zelfs verstandig. Sneller live zijn kan meer waard zijn dan de mooiste architectuur. Het wordt pas een probleem als de rente zo hoog oploopt dat je vrijwel niets meer aan nieuwe functionaliteit toekomt.
Signalen dat de rekening oploopt
Kleine wijzigingen kosten onevenredig veel tijd. Een aanpassing die op papier een uur zou moeten zijn, kost een dag omdat niemand precies weet wat er nog meer op vastzit.
Niemand durft bepaalde onderdelen aan te raken. Er is een module die "gewoon werkt" en waar met een grote boog omheen wordt gelopen. Dat is geen stabiliteit; dat is onzichtbaar risico.
Releases worden spannend. Elke livegang gaat gepaard met een knoop in de maag en een handmatige checklist. Ontbreken geautomatiseerde tests, dan is elke wijziging in feite een gok.
Je loopt achter op versies. Het framework, de programmeertaal of de database draait op een versie die geen beveiligingsupdates meer krijgt. Dat is niet alleen een technisch probleem: het maakt je kwetsbaar en het bemoeilijkt certificeringen en klantaudits.
Nieuwe ontwikkelaars komen moeizaam binnen. Duurt het maanden voordat iemand productief is, dan zegt dat iets over de leesbaarheid en documentatie van de code en het maakt je afhankelijk van enkele personen.
De business hoort steeds "dat kan niet". Het duidelijkste signaal is dat de techniek de strategie is gaan bepalen in plaats van andersom.
Herken je een aantal van deze signalen niet in maatwerksoftware, maar in een spreadsheet die stilletjes is uitgegroeid tot bedrijfskritische tool? Ook dat is technische schuld, lees er meer over in Van Excel naar webapplicatie: wanneer is je spreadsheet een risico.
Maak de kosten van uitstel zichtbaar
De lastigste kant van dit vraagstuk is dat niets doen gratis lijkt. De software werkt immers nog. De kosten zitten verstopt in zaken die je niet op een factuur ziet: doorlooptijd van wijzigingen, tijd die weglekt aan storingen en workarounds en kansen die je laat liggen omdat een integratie of nieuwe dienst technisch niet haalbaar is.
Je hoeft daar geen uitgebreid onderzoek voor te doen. Houd een periode bij hoeveel tijd er per maand naar onderhoud en incidenten gaat, hoe lang een gemiddelde wijziging van idee tot productie duurt en hoe vaak een release moet worden teruggedraaid. Die drie getallen maken het gesprek concreet en geven je later een meetpunt om te zien of de investering iets heeft opgeleverd.
Drie routes, en wanneer je ze kiest
Route 1: doorontwikkelen en gericht opruimen. Werkt de applicatie functioneel goed en is de architectuur in de basis gezond, dan is herbouwen zelden verstandig. Kies dan voor structureel onderhoud: versies bijwerken, tests toevoegen rond de onderdelen die je het vaakst aanpast en per sprint een vast deel van de tijd reserveren voor opruimen. Hoe dat onderhoud er in de praktijk uitziet, lees je in Software-onderhoud: waarom je maatwerkapplicatie ook ná de livegang aandacht nodig heeft. Dit is de goedkoopste route en vaak de juiste.
Route 2: gefaseerd vervangen. Is één deel van het systeem het knelpunt. Bijvoorbeeld de facturatie of de koppeling met een extern pakket, dan vervang je alleen dat deel. Je zet de nieuwe module naast het bestaande systeem, leidt het verkeer stap voor stap om en schakelt het oude onderdeel pas uit als het nieuwe zich bewezen heeft. Deze aanpak geeft snel resultaat en houdt het risico klein.
Route 3: herbouwen. Dit is de zwaarste route en is te verdedigen wanneer de onderliggende technologie geen ondersteuning meer krijgt, wanneer de gegevensstructuur de bedrijfsvoering in de weg zit of wanneer je proces zo veranderd is dat de oude software een ander bedrijf beschrijft dan het bedrijf dat je nu bent. Let op de klassieke valkuil: een herbouw die maanden onzichtbaar blijft en pas aan het eind "in één keer" live gaat. Knip het op, lever in stukken op en houd beide systemen een periode naast elkaar.
Vier dingen die het verschil maken
Begin bij het proces, niet bij de code. Herbouw je een systeem dat jarenlang is meegegroeid, dan bouw je zonder nadenken ook de omwegen na. Bepaal eerst hoe het proces er idealiter uitziet.
Zorg eerst voor een vangnet. Geautomatiseerde tests rond het gedrag dat je niet mag breken, geven je de vrijheid om te veranderen. Zonder dat vangnet wordt elke ingreep voorzichtig en traag.
Neem de data serieus. Migraties zijn vaak het moeilijkste onderdeel en worden het vaakst onderschat. Plan ruimte in voor opschonen, testmigraties en een terugvalscenario.
Maak onderhoud structureel. Een eenmalige opruimactie brengt je terug bij af zodra de waan van de dag toeslaat. Ruimte voor updates en refactoring hoort standaard in je planning te zitten, net als back-ups en monitoring.
Tot slot
Verouderde software hoeft geen probleem te zijn. Het wordt er pas een als niemand meer overzicht heeft over wat het je kost. Breng dat in kaart, kies bewust tussen onderhouden, gefaseerd vervangen of herbouwen, en voer die keuze uit in stappen die je kunt controleren.
Wil je weten waar jouw applicatie staat en welke route het meeste oplevert? Bekijk hoe wij bij onze dienstverlening naar bestaande software kijken, of neem contact op met CodeBros — we kijken graag met je mee naar de code, de architectuur en de praktische stappen die daarbij horen.