De vraag of je bestaande maatwerksoftware moet herschrijven is er een die veel organisaties voor zich uitschuiven. Het systeem werkt nog, min of meer. Maar elke nieuwe feature kost meer tijd dan de vorige, bugs duiken op plekken op waar niemand ze verwacht, en developers kijken steeds vaker bedenkelijk als er weer een aanpassing op de planning staat.
Op dat moment komen twee opties op tafel: software uitbreiden, en verder bouwen op wat er is, of opnieuw beginnen met een herschrijving. Beide keuzes hebben verstrekkende gevolgen voor tijd, budget en continuïteit. En toch wordt de beslissing vaak gemaakt op basis van onderbuikgevoel in plaats van een heldere analyse.
Dit artikel helpt je die analyse wél te maken. Je leest welke signalen erop wijzen dat herschrijven de enige logische stap is, wanneer uitbreiden nog steeds de slimmere keuze is, en welke vragen je moet stellen voordat je een beslissing neemt die je voor de komende jaren vastlegt.
Wie zegt dat software moet worden "aangepakt", bedoelt daar vaak twee heel verschillende dingen mee. Het onderscheid lijkt technisch, maar raakt direct aan strategie, planning en risico.
Software uitbreiden betekent dat je verder bouwt op de bestaande codebase. Je voegt functionaliteit toe, past bestaande onderdelen aan of integreert nieuwe systemen, zonder de onderliggende structuur te vervangen. De basis blijft staan. Dat is in veel gevallen de juiste aanpak: sneller, goedkoper en met minder risico op verstoringen in wat al werkt.
Software herschrijven is iets fundamenteel anders. Je vervangt de bestaande code, deels of volledig, door een nieuwe implementatie. Soms met een andere technologie, soms met dezelfde stack maar een andere architectuur. De bedoeling is niet om iets toe te voegen, maar om een solide nieuwe basis te leggen waarop je daarna wél kunt bouwen.
De verleiding bestaat om herschrijven te zien als "uitbreiden, maar dan grondig". Dat is een misvatting die projecten in de problemen brengt. Een herschrijving heeft een ander tijdsbestek, een ander risicoprofiel en vraagt andere beslissingen rondom datamigratie, parallelle systemen en overdracht van bestaande logica.
Tegelijk is uitbreiden niet altijd de veilige keuze. Wie blijft bouwen op een fundament dat niet meer deugt, stapelt risico op risico. De kosten van die aanpak worden vaak pas zichtbaar als het te laat is, iets wat nauw samenhangt met wat technical debt op de lange termijn met een systeem doet.
De keuze tussen herschrijven en uitbreiden is dus geen technische voorkeur. Het is een strategische afweging die begint met een eerlijke beoordeling van de staat van je huidige systeem.
Niet elk systeem dat verouderd aanvoelt, is ook daadwerkelijk aan vervanging toe. Maar er zijn specifieke signalen die erop wijzen dat uitbreiden geen duurzame optie meer is. Hieronder staan de meest voorkomende.
Een gezonde codebase maakt het mogelijk om nieuwe functionaliteit toe te voegen zonder dat bestaande onderdelen instabiel worden. Wanneer dat niet meer het geval is, is er iets structureel mis.
Het herken je aan het patroon: een aanpassing die in theorie een dag werk is, kost een week. Developers moeten eerst begrijpen hoe tien andere onderdelen op elkaar reageren voordat ze één regel kunnen wijzigen. Elke release gaat gepaard met spanning over wat er onbedoeld kapot gaat. Op dat punt werkt het team niet meer mét de software, maar tegen haar.
Elke codebase heeft technical debt. Dat is normaal. Snelle beslissingen, tijdsdruk, veranderde inzichten: ze laten allemaal sporen na in de code. Dat wordt pas een probleem als die schuld niet meer wordt afgelost, maar jaar na jaar verder oploopt.
Structurele technical debt is zichtbaar in code die niemand meer durft aan te raken, in ontbrekende tests, in systemen die draaien op versies die al jaren niet meer worden ondersteund. Het is geen technisch ongemak meer, het is een bedrijfsrisico.
Software wordt gebouwd voor een bepaalde context. Die context verandert. Een systeem dat jaren geleden goed functioneerde voor een handvol gebruikers en een beperkt aantal processen, is niet vanzelfsprekend geschikt voor de situatie van nu.
Wanneer schaalproblemen niet op te lossen zijn met optimalisaties of uitbreidingen, maar zitten ingebakken in hoe het systeem fundamenteel is opgezet, is dat een architectuurprobleem. En architectuurproblemen los je niet op door er omheen te bouwen. De manier waarop je software architecture aanpakt heeft directe gevolgen voor hoe lang een systeem meegaat.
In veel organisaties is er één developer, soms twee, die het systeem echt begrijpen. Zij weten waarom bepaalde keuzes zijn gemaakt, waar de uitzonderingen zitten en welke onderdelen je beter niet aanraakt. Die kennis zit niet in documentatie, niet in de code zelf, maar in hun hoofd.
Dat is een kwetsbare situatie. Als die persoon vertrekt, ziek wordt of gewoon niet beschikbaar is, staat het team stil. Een systeem dat niet overdraagbaar is, is per definitie een systeem met een beperkte toekomst.
Moderne software werkt zelden op zichzelf. Koppelingen met andere systemen, platformen en diensten zijn de norm. Wanneer elke nieuwe integratie een project op zich wordt, vol workarounds en tijdelijke oplossingen, is dat een teken dat de onderliggende structuur het niet meer toelaat.
De vraag bij legacy system integration is altijd: is de moeite die een koppeling kost een gevolg van de complexiteit van de integratie zelf, of van de staat van het eigen systeem? Als het antwoord structureel het laatste is, lost uitbreiden dat niet op.
Herschrijven heeft iets aantrekkelijks. Een frisse start, geen last van oude beslissingen, eindelijk de kans om het goed te doen. Maar die aantrekkingskracht is ook een valkuil. Een herschrijving is een van de zwaarste ingrepen die je op een softwaresysteem kunt uitvoeren, en in een aantal situaties is het simpelweg niet de juiste keuze.
Niet elk oud systeem is een slecht systeem. Soms is de onderliggende bedrijfslogica degelijk, beproefd en waardevol, maar is de omhulling verouderd. In dat geval is application modernization vaak een slimmere route dan een volledige herschrijving. Je behoudt wat werkt en vervangt wat niet meer voldoet, zonder alles opnieuw te hoeven uitdenken.
Een herschrijving betekent ook dat je alle bestaande logica opnieuw moet implementeren. Dat klinkt eenvoudig, maar in de praktijk zit er in elk volwassen systeem kennis verwerkt die nergens expliciet is gedocumenteerd. Die kennis raakt bij een herschrijving al snel verloren, met fouten en gemiste randgevallen als gevolg.
Een herschrijving kost tijd. Soms maanden, soms langer. Gedurende die periode loopt de ontwikkeling van nieuwe functionaliteit grotendeels stil, of moet die in twee systemen parallel worden bijgehouden. Voor organisaties die afhankelijk zijn van snelle doorontwikkeling is dat een reële bedreiging.
Als de business het zich niet kan veroorloven om zes tot twaalf maanden in een lagere versnelling te rijden, is een herschrijving op dat moment geen verantwoorde keuze, hoe verleidelijk ook.
Soms is een trage of instabiele ontwikkeling geen gevolg van slechte code, maar van gebrekkige werkafspraken, onduidelijke prioriteiten of een team zonder de juiste structuur. Een herschrijving lost dat niet op. Wie een slecht georganiseerd proces meeneemt naar een nieuwe codebase, eindigt na verloop van tijd op dezelfde plek.
Voor je concludeert dat de software het probleem is, is het de moeite waard om eerlijk te kijken naar hoe het ontwikkelproces is ingericht.
Een herschrijving die halverwege stopt omdat het budget op is, is erger dan geen herschrijving. Je zit dan met twee halfwerkende systemen en een team dat energie heeft gestoken in iets wat niets heeft opgeleverd. Als de middelen er niet zijn om een herschrijving volledig door te zetten, is het beter om die keuze niet te maken.
Signalen herkennen is één ding. Een gefundeerde beslissing nemen is een ander. De keuze tussen software herschrijven en uitbreiden verdient een gestructureerde afweging, geen beslissing in een vergadering op basis van frustratie over de laatste sprint.
De vragen hieronder helpen je die afweging te maken. Ze hebben geen eenduidig antwoord, maar ze dwingen je om de juiste dingen expliciet te maken.
Dit is de vraag die het vaakst wordt overgeslagen. De kosten van herschrijven zijn zichtbaar en voelen groot. De kosten van niet herschrijven zijn verspreid over tijd en daardoor makkelijk te onderschatten.
Tel op wat langzame ontwikkeling, bugs, downtime en workarounds de komende jaren kosten in developer-uren, gemiste kansen en bedrijfsrisico. Zet dat af tegen de investering van een herschrijving. Dat is geen exacte berekening, maar het dwingt je om de status quo als een actieve keuze te behandelen, niet als een neutrale standaard.
Sommige systemen hebben problemen die met gerichte ingrepen zijn op te lossen. Andere hebben problemen die zo diep in de structuur zitten dat elke oplossing tijdelijk is. Het verschil bepaalt of uitbreiden nog zin heeft.
Een eerlijk antwoord op deze vraag vereist technische diepgang. Het is precies het soort beoordeling waarbij een externe blik waardevol is, iemand die zonder belang bij de uitkomst naar de staat van het systeem kan kijken.
Een herschrijving vraagt capaciteit. Capaciteit die dan niet naar nieuwe functionaliteit gaat. Afhankelijk van hoe kritisch het systeem is voor de dagelijkse operatie, kan dat een acceptabel tijdelijk ongemak zijn of een onverantwoord risico.
Breng in kaart welke processen afhankelijk zijn van het systeem, welke alternatieven er zijn voor de duur van een herschrijving, en wat de gevolgen zijn als de planning uitloopt. Dat laatste gebeurt vaker dan niet.
Een herschrijving uitvoeren met een team dat het huidige systeem nauwelijks begrijpt, of met developers die al volledig bezet zijn met dagelijks onderhoud, is een recept voor problemen. De technische uitvoering van een herschrijving stelt andere eisen dan het onderhoud van bestaande software.
Als de interne capaciteit er niet is, is dat geen reden om af te zien van een herschrijving, maar wel een reden om te kijken naar wat er van buiten nodig is. De afweging tussen software consultancy vs in-house development speelt hier direct een rol.
Dit lijkt een voor de hand liggende vraag, maar wordt verrassend vaak niet gesteld. Een herschrijving is geen kopie van het bestaande systeem in nieuwe code. Het is een kans om opnieuw te bepalen wat het systeem moet doen, voor wie, en hoe.
Als die vraag niet beantwoord wordt voor de herschrijving begint, eindigt het project met een nieuwe codebase die dezelfde problemen heeft als de oude.
De beslissing om te herschrijven is genomen. Dan begint het echte werk, en dat valt in de praktijk bijna altijd zwaarder uit dan vooraf gedacht. Niet omdat een herschrijving per definitie mislukt, maar omdat de complexiteit ervan structureel wordt onderschat.
De gedachte achter een herschrijving is vaak: we beginnen opnieuw, zonder de ballast van het oude systeem. Die gedachte is begrijpelijk, maar zelden realistisch. Het bestaande systeem heeft jaren aan bedrijfslogica geabsorbeerd. Uitzonderingen, randgevallen, gedrag dat nergens is gedocumenteerd maar wel door gebruikers wordt verwacht. Al die kennis moet worden overgebracht naar het nieuwe systeem, bewust of onbewust.
Wie dat onderschat, bouwt een systeem dat technisch misschien beter is, maar functioneel tekortschiet op plekken die pas zichtbaar worden na livegang.
In vrijwel elke herschrijving zit een datavraagstuk. Het oude systeem heeft data opgebouwd in een structuur die past bij de oude architectuur. De nieuwe architectuur vraagt vaak om een andere structuur. Die twee met elkaar in overeenstemming brengen, zonder dataverlies en zonder de continuïteit te verstoren, is technisch complex en tijdrovend.
Datamigratie wordt in planningen consequent te licht ingeschat. Reken er altijd meer tijd voor in dan je denkt nodig te hebben.
In de meeste gevallen kan het oude systeem niet gewoon worden uitgezet terwijl het nieuwe wordt gebouwd. De organisatie draait door. Dat betekent dat er een periode is waarin twee systemen naast elkaar bestaan: het oude in productie, het nieuwe in ontwikkeling.
Die situatie brengt druk met zich mee. Bugfixes en aanpassingen moeten soms in beide systemen worden doorgevoerd. Het team moet schakelen tussen onderhoud en nieuwbouw. En hoe langer die periode duurt, hoe hoger de kosten en de frustratie oplopen. Een goed gestructureerd softwareproject zorgt ervoor dat deze fase zo kort en beheerst mogelijk blijft.
Een nieuw systeem dat live gaat, is geen garantie voor beter gedrag. Functionaliteit die in het oude systeem jarenlang stabiel werkte, kan in het nieuwe systeem anders uitpakken, simpelweg omdat de implementatie anders is. Zonder een gedegen teststrategie kom je daar pas achter als gebruikers het melden.
Investeren in geautomatiseerde tests is bij een herschrijving geen luxe maar een noodzaak. Het is de enige manier om met enige zekerheid te zeggen dat het nieuwe systeem doet wat het moet doen.
Dat is geen fatalisme, maar een patroon dat breed wordt herkend in de sector. Herschrijvingen raken verstrikt in onverwachte complexiteit, gewijzigde inzichten tijdens de bouw, of externe afhankelijkheden die niet op tijd beschikbaar zijn. Een realistische planning houdt daar rekening mee, met buffers die niet worden wegbezuinigd zodra de druk toeneemt.
Veel organisaties worstelen lang met de vraag of ze moeten herschrijven of uitbreiden, simpelweg omdat niemand intern de positie heeft om die vraag objectief te beantwoorden. Developers die dagelijks met het systeem werken, hebben een mening gekleurd door gewenning of frustratie. Management kijkt naar kosten en risico, maar mist de technische diepgang. En iedereen heeft belang bij een uitkomst die de eigen positie niet onder druk zet.
Een externe partij doorbreekt dat patroon.
Een softwareconsultant die wordt gevraagd naar de staat van een systeem, heeft geen belang bij een bepaalde uitkomst. Hij kijkt naar de codebase zonder de emotionele lading van jaren werken met hetzelfde systeem. Dat maakt het mogelijk om eerlijk te beoordelen wat er is, wat het kost om het te onderhouden, en of uitbreiden nog een reële optie is.
Dat is niet alleen een technische beoordeling. Een goede consultant vertaalt de technische realiteit naar businesstermen: wat betekent de staat van dit systeem voor de groei van de organisatie, voor de afhankelijkheid van specifieke mensen, voor de mogelijkheid om snel te reageren op veranderingen in de markt.
Soms is de waarde van een externe blik niet dat die een knoop doorhakt, maar dat die de interne discussie ontdoet van aannames. Wat intern als vanzelfsprekend wordt beschouwd, is dat voor een buitenstaander niet. Vragen die intern nooit worden gesteld, komen bij een externe beoordeling vanzelf op tafel.
Die second opinion hoeft geen groot traject te zijn. Een gerichte technische review van het bestaande systeem, gecombineerd met een gesprek over de businesscontext, levert vaak al genoeg inzicht op om een gefundeerde beslissing te nemen.
Als de beslissing eenmaal is genomen, verandert de rol van een externe partij. Dan gaat het niet meer om adviseren, maar om meehelpen uitvoeren. Of dat betekent dat een extern team de herschrijving volledig op zich neemt, of dat er tijdelijk capaciteit wordt toegevoegd aan een intern team, hangt af van de situatie.
De voordelen van dedicated development teams komen bij een herschrijving goed tot hun recht. Een team dat volledig gefocust is op het nieuwe systeem, zonder de afleiding van dagelijks onderhoud aan het oude, werkt efficiënter en levert betere resultaten dan een intern team dat beide moet combineren.
Software herschrijven is geen beslissing die je neemt omdat het systeem oud is, of omdat developers klagen over de codebase. Het is een strategische keuze die gerechtvaardigd moet worden door een eerlijke beoordeling van wat het systeem kost, wat het blokkeert en wat uitbreiden op de lange termijn nog oplevert.
De signalen zijn herkenbaar als je weet waar je op moet letten. Een codebase die nieuwe functionaliteit actief tegenwerkt, structurele technical debt die niet meer wordt afgelost, een architectuur die de huidige schaal niet aankan: het zijn geen technische details maar businessproblemen. Tegelijk is herschrijven geen universeel antwoord. Wie herschrijft zonder een helder beeld van wat het nieuwe systeem moet doen, of zonder de capaciteit om het traject volledig door te zetten, lost het ene probleem op en creëert het andere.
De beslissing verdient tijd, structuur en een eerlijke blik, ook van buiten. Bij Tuple helpen we organisaties bij precies deze afweging: van een technische beoordeling van het bestaande systeem tot de uitvoering van een herschrijving of een gerichte uitbreiding. Neem contact met ons op als je wilt weten waar jouw systeem staat en welke stap als volgende logisch is.
Bij software moderniseren vervang je onderdelen van een bestaand systeem stap voor stap, zonder de hele codebase opnieuw te schrijven. Je behoudt wat werkt en vernieuwt wat niet meer voldoet. Software herschrijven gaat verder: de bestaande code wordt vervangen door een nieuwe implementatie, soms met een andere architectuur of technologie. Moderniseren is vaak minder ingrijpend en beter te faseren; herschrijven is radicaler maar soms de enige optie als de basis structureel niet meer deugt.
Dat verschilt sterk per systeem, maar reken op minimaal drie tot zes maanden voor een beperkt systeem en een jaar of langer voor complexe platformen. De doorlooptijd wordt bepaald door de omvang van de bestaande functionaliteit, de complexiteit van de datamigratie en de beschikbare capaciteit. Planningen lopen bij herschrijvingen vaker uit dan bij andere projecten, dus bouw altijd ruimte in.
In de meeste gevallen wel, maar het vraagt goede afspraken. Oud en nieuw draaien dan een periode parallel, wat betekent dat aanpassingen soms in beide systemen moeten worden doorgevoerd. Hoe langer die parallelle fase duurt, hoe meer druk dat legt op het team. Een duidelijke planning met een harde overgangsdatum helpt om die fase beheersbaar te houden.
Als elke uitbreiding meer kapot maakt dan toevoegt, als de architectuur schaalproblemen heeft die niet met optimalisaties zijn op te lossen, of als de kennis van het systeem zo geconcentreerd is bij één of twee mensen dat overdracht praktisch onmogelijk is. Op dat punt is uitbreiden geen investering meer maar uitstel van een onvermijdelijke beslissing.
Niet per se, maar het is in de meeste gevallen verstandig. Intern ontbreekt vaak de objectiviteit om de staat van een eigen systeem eerlijk te beoordelen. Een externe technische review hoeft geen groot traject te zijn, maar geeft wel het onafhankelijke inzicht dat nodig is om een beslissing te nemen die je voor jaren vastlegt.
Als Marketing & Sales Executive bij Tuple maak ik gebruik van mijn expertise op het gebied van digitale marketing terwijl ik voortdurend streef naar persoonlijke en professionele groei. Mijn sterke interesse in IT motiveert me om op de hoogte te blijven van de nieuwste technologische ontwikkelingen.
Soms is de eerlijkste conclusie dat verder bouwen op bestaande software meer kost dan het oplevert. Tuple helpt je die afweging maken: van een technische beoordeling van je huidige systeem tot de uitvoering van een herschrijving of gerichte uitbreiding.
Bespreek je situatie met Tuple
