Are Rewrites always a Bad Idea? - Adele Carpenter - NDC Oslo 2024

The key reasons to consider a rewrite:

• There is a desire to functionally change the application
• No small steps available to improve the codebase
• The team lacks required skills and doesn’t wish to acquire them
• The service is small with well-defined scope

Before starting a rewrite:

• Conduct thorough audit of current application functionality
• Look for evidence that proves rewrite is wrong rather than right
• Treat initial phase as discovery/feasibility study
• Be prepared to walk away if scope is larger than expected
• Break rewrite into smaller deployable chunks

Avoid common pitfalls:

• Resume-driven development (choosing new tech just to add to resume)
• Assuming predecessors made poor decisions
• Underestimating complexity of existing system
• Taking on too large a scope
• Not delivering value early

Successful rewrite approach:

• Use strangler fig pattern for gradual replacement
• Keep tech stack choices aligned with team expertise
• Focus on consistency over perfection
• Get early user feedback
• Document thoroughly including “todos” and loose ends

Key considerations:

• Rewrite must solve actual user pain points
• Team skills and preferences matter more than “best” technology
• Small, well-defined scope is crucial
• Early stakeholder buy-in through quick wins
• Leadership and communication are as important as technical skills