Rewrite or refactor? Four questions that settle it

The argument everyone has

Someone says the codebase is a mess and should be rewritten. Someone else says rewrites always fail. Both are sometimes right.

Four questions

1. What exactly is broken? Write it down. "Hard to work with" isn't an answer. "Every change to billing takes three weeks because of X" is. If you can name a specific, bounded cause, you probably need a refactor.

2. Can you replace it piece by piece? If you can put a seam around one part, move it, and keep the rest running, do that. Gradually strangling an old system is slower on paper and much safer in practice.

3. Do you know what the old system does? Old systems carry rules nobody remembers writing: edge cases, legal requirements, a workaround for a customer from 2017. A rewrite that misses them will rediscover them in production.

4. Can the business wait? A rewrite means months of little visible progress, usually while the old system still needs fixes. If the answer is "not really", the rewrite is off the table, however tempting.

When a rewrite is right

When the technology is truly end of life, when the data model is wrong at the root, or when the system is small enough that rebuilding costs less than understanding. These cases exist. They're rarer than the argument suggests.

What to do this month

1. Write a one-paragraph problem statement. If you can't, you aren't ready to decide.
2. Pin down the old behaviour. List the five riskiest things the system does and write tests that capture them as they are today.
3. Find the first seam. Pick the smallest piece that can be moved without touching the rest.
4. Time-box a spike. Two weeks to build that one piece the new way. Judge on what you learn.
5. Decide with numbers. Compare the cost of living with the problem for a year against the cost of the fix.