When to Fix and When to Replace

A particular decision you often have to justify as a software architect is the choice of whether to continue using some existing code, or whether to throw it away and replace it with something else. Well, you rarely have to justify the decision to keep what you already have; you often have to justify its replacement.

This is as it should be. While it's satisfying – even calming – to think of leaving all that legacy cruft behind and starting on a greenfield implementation, there are good reasons to avoid doing so. The existing code may seem buggy and hard to understand, but your team has existing experience with it and probably knows where the problems and limitations are. The same cannot be said of the as-yet nonexistent replacement, which will probably bring its own difficulties and bugs.

It's important to realize now that this argument is not the same as the sunk-cost fallacy. That would be to argue that you shouldn't throw away...