Resisting The Rewrite Until You Understand What It Is For

The urge to replace an inherited system is strongest at the moment you know least about it.

The rewrite instinct arrives early and feels like judgement rather than impulse. The existing system is hard to read, its structure looks wrong, and you can see a cleaner arrangement. What you cannot see, in week two, is the accumulated response to reality contained in the mess. The odd special case that handles a genuine customer situation. The awkward ordering that exists because a downstream system misbehaves otherwise. The check that looks paranoid and was added after an incident nobody wrote up. A rewrite discards all of it at once, and rediscovers it one production failure at a time.

There is a further problem, which is that a rewrite competes with a moving target. The existing system continues to be changed while the replacement is built, so the replacement is chasing a specification that will not hold still, and the honest comparison is never between old and new but between old plus continued improvement and new plus everything not yet reimplemented. Projects that start with a clear scope end up two thirds finished and unable to move, maintaining two systems and getting the benefits of neither. This is common enough that anyone proposing a full replacement should be asked how they intend to avoid it.

The alternative is unglamorous and works. Improve the part you are already touching, leave it slightly better than you found it, and let the improvement follow the actual work rather than a plan. Over a year this reshapes the areas that matter, which are the areas that change, and leaves the stable parts alone, which is correct because stable code that works is not a problem regardless of how it looks. There is a time to replace something wholesale, usually when the underlying model is genuinely wrong rather than merely untidy. That judgement should come after understanding, not instead of it.