## De eeuwige discussie: refactor vs rewrite
Elke team met groeiende technical debt komt op dit punt: moeten we dit fixen of opnieuw bouwen?
Wat is refactor vs rewrite?
Refactor Het verbeteren van interne code structuur zonder extern gedrag te veranderen.
Rewrite Het volledig opnieuw bouwen van een systeem of component.
De beslissingsboom
Stap 1: Is het systeem levensvatbaar?
Vragen: - Doet het systeem wat het moet doen? - Zijn gebruikers tevreden? - Is het business model bevestigd?
Als NEE: Rewrite is mogelijk. Als het product niet werkt, is het tech niet het probleem.
Als JA: Ga naar stap 2.
Stap 2: Is het architecture solide?
Vragen: - Zijn de kernabstractions goed? - Zijn de scheidingen van concerns logisch? - Is het data model juist?
Als NEE: Architecture refactor first. Probeer niet te rewrite zonder nieuwe architecture.
Als JA: Ga naar stap 3.
Stap 3: Hoeveel debt is er?
Vragen: - Percentage van code dat problematisch is - Impact op velocity (snelheid van nieuwe features) - Number of bugs per release
< 20% debt: Refactor 20-50% debt: Partial rewrite > 50% debt: Full rewrite kan nodig zijn
Stap 4: Wat zijn de business requirements?
Vragen: - Is er een deadline voor nieuwe features? - Is er budget en tijd voor rewrite? - Kan de business stilstand voor ontwikkeling?
Als dringend: Refactor in small steps Als ruimte: Plan rewrite
Wanneer refactor
Kies refactor als: - Architecture is fundamenteel goed - Debt is lokaal, niet systeem-breed - Team kent de code goed - Time-to-market is belangrijk - Budget is beperkt
Refactor strategie: - Boy Scout rule: laat de code schoner achter dan je hem vond - Strangler fig pattern: vervang stukje bij beetje - Test-driven refactor: schrijf tests eerst, dan refactor
Wanneer rewrite
Kies rewrite als: - Architecture is fundamenteel fout - Technology is verouderd (end-of-life) - Team kent code niet (originale developers vertrokken) - Business requirements veranderd fundamenteel - Technical debt remt ontwikkeling (>50%)
Rewrite strategie: - Parallel development (naast bestaand systeem) - Incrementele migratie - Feature parity check - Data migration plan
De valkuilen van rewrite
1. Tweede systeem effect
"De eerste keer maak je een mess, de tweede keer maak je iets dat niet werkt."
Oplossing: Bewust zijn van dit effect, humility hebben.
2. Te optimistische planning
Rewrites nemen altijd langer dan gepland.
Oplossing: Verdubbel je tijdinschatting.
3. Vergeten requirements
In de rush naar nieuw, vergeten we edge cases die in de oude code staan.
Oplossing: Documenteer oude systeem eerst (ADR, user flows, edge cases).
4. Business stagneert
Tijdens rewrite geen nieuwe features.
Oplossing: Parallell development of kleinere rewrites.
Praktisch voorbeeld: SaaS platform
Situatie: - 3 jaar oud platform - React (oude versie) + custom backend - 60% technical debt - Team klaagt over velocity - Nieuwe features nemen steeds langer
Opties:
1. Refactor in-place - Upgrade React stap voor stap - Refactor module voor module - Voortgang: ~70% van tijd kan nog nieuwe features - Tijd: 6-12 maanden
2. Partial rewrite - Nieuwe modules in Next.js - Oude modules langzaam migreren - Voortgang: ~40% van tijd kan nog nieuwe features - Tijd: 8-16 maanden
3. Full rewrite - Opnieuw bouwen in Next.js - Geen nieuwe features tijdens rewrite - Voortgang: 0% nieuwe features - Tijd: 12-24 maanden
Recommendation: Voor de meeste bedrijven is optie 2 (partial rewrite) het beste balance.
Rol van fractional CTO
Een fractional CTO helpt bij: - Architecture assessment - Debt impact analysis - Rewrite vs refactor beslissing - Migration planning - Team begeleiding tijdens transitie - Stakeholder management
Conclusie
Rewrite is niet zelden het antwoord. Meestal is een combinatie van: 1. Fundamentele architecture fixes 2. Strategische rewrites van probleem modules 3. Geleidelijke migratie
Key lessons: - Wees humility: het oude systeem werkt voor een reden - Plan x2 je tijdinschatting - Communicatie met stakeholders is cruciaal - Measure velocity voor en na