Wanneer een rewrite wél (en niet) de oplossing is.

Elke developer komt op een punt dat ze naar de codebase kijken en denken: "Het is makkelijker om dit helemaal opnieuw te schrijven." Hoewel dat soms waar is, is een complete rewrite vaak een van de gevaarlijkste beslissingen die een softwarebedrijf kan nemen.

De verleiding van de lege pagina

In een nieuwe codebase heb je geen legacy-bugs, geen vreemde workarounds en geen verouderde architectuurkeuzes. Maar je hebt ook geen jaren aan edge cases die in de huidige code zijn opgelost. Een rewrite onderschat bijna altijd de complexiteit van de bestaande business logica.

Wanneer niet herschrijven?

Als de reden puur "de code is lelijk" of "we willen een moderner framework gebruiken" is, is een rewrite zelden gerechtvaardigd. In de meeste gevallen is een stapsgewijze refactor — waarbij je onderdelen één voor één vervangt terwijl het systeem blijft draaien — een veel veiligere en productievere weg.

Wanneer wél herschrijven?

Een rewrite wordt interessant wanneer de fundamentele aannames van het systeem niet meer kloppen. Bijvoorbeeld wanneer de schaalbaarheid tegen een harde grens loopt die niet met refactoring op te lossen is, of wanneer de kosten van onderhoud en het toevoegen van features hoger zijn geworden dan de kosten van een nieuwbouwproject.