𝗛𝗼𝘄 𝗪𝗲 𝗗𝗲𝗰𝗶𝗱𝗲 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗥𝗲𝘄𝗿𝗶𝘁𝗲
Every developer faces this moment.
The codebase is slow. Adding features takes too long. New hires struggle to understand the system. Someone eventually suggests a full rewrite.
The team usually splits into two groups. One group wants to start fresh. The other group fears the failure of past rewrites. Both sides have valid points.
A rewrite is not a magic fix. It often takes longer than planned. You end up maintaining two systems at once. You might even repeat the same mistakes in the new version.
A rewrite makes sense in these specific cases:
• The data model is fundamentally wrong for the business. • The technology is dead and has no security updates. • The business needs have changed so much that the original system is obsolete. • No one on the current team understands how the system works.
Even then, do not do a big bang replacement. Use a strangler fig pattern. Build the new system piece by piece alongside the old one.
Most of the time, you actually need to refactor.
Refactoring is the right choice when:
• You can still add features, even if it is slow. • The team understands the current code. • The mess is limited to specific modules. • The business cannot stop shipping new features.
Before you choose, ask why the code became bad.
If the problem is technical debt, refactor the worst parts. If the problem is a lack of code reviews or poor culture, a rewrite will not help. You will just build a new mess with the same old habits.
Ask these questions before you decide:
• Can we fix the worst parts in isolation? • Is the data model broken for current business needs? • What knowledge will we lose if we start over? • Does the business have the stability to handle a long transition?
Starting over feels good. Finishing the rewrite is the hard part. Most of the time, a structured refactoring plan is safer and more effective.
Source: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk