When is it good (if ever) to scrap production code and start over? [closed]

Answer 1

In terms of business value, I would think it's extremely rare that a real case can be made for a rewrite due solely to the internal state of the code. If the product's customer-facing and is currently live and bringing in money (i.e. is not a mothballed or unreleased product), then consider that:

• You already have customers using it. They're familiar with it, and might have built some of their own assets around it. (Other systems that interface to it; products based on it; processes they'd have to change; staff they'd maybe have to retrain). All of this costs the customer money.
• Re-writing it might cost less in the long term than making difficult changes and fixes. But you can't quantify that yet, unless your app is no more complex than Hello World. And a re-write means a re-test and a redeploy, and probably an upgrade path for your customers.
• Who says the re-write will be any better? Can you honestly say your firm is writing sparkly code now? Have the practices that turned the original code to spaghetti been corrected? (Even if the main culprit was a single developer, where were his peers and management, ensuring quality through reviews, testing, etc.?)

In terms of technical reasons, I'd suggest it could be time for a major rewrite if the original has some technical dependencies that have become problematic. e.g. a third party dependency that's now out of support, etc.

In general though, I think the most sensible move is to refactor piece by piece (very small pieces if it's really that bad), and improve the internal architecture incrementally rather than in one big drop.

Answer 2

As early as possible. Whenever you get a premonition that your code is slowly turning into an ugly beast that is very likely to consume your soul and give you headaches, and you know the problem is in the underlying structure of the code (so any fix would be a hack, e.g. introduce a global variable), then it's time to start over.

For some reasons people don't like throwing away precious code, but if you feel your better off starting over, you are probably right. Trust your instinct and remember that it wasn't a waste of time, it taught you one more way of NOT approaching the problem. You could (should) always use a version control system so your baby is never really lost.

Answer 3

Scrap old code early and often. When in doubt, throw it out. The hard part is convincing non-technical folks of the cost-to-maintain.

So long as the value derived appears to be greater than the cost to operate and maintain, there's still positive value flowing from the software. The question surrounding a rewrite this: "will we get even more value from a rewrite?" Or alternatively "How much more value will we get from a rewrite?" How many person-hours of maintenance will you save?

Remember, the rewrite investment is once only. The return on the rewrite investment lasts forever. Forever.

Focus the value question down to specific issues. You listed a bunch of them above. Stick with that.

• "Will we get more value by reducing cost through dropping the junk that we don't use but still have to wade through?"

• "Will we get more value from dropping the junk that's unreliable and breaks?"

• "Will we get more value if we understand it -- not by documenting, but by replacing with something we built as a team?"

Do you homework. You'll have to confront the following show-stoppers. These will originate somewhere in your executive foodchain from someone who'll respond as follows:

• "Is it broken?" And when you say "It's not crashed as such," They'll say "It's not broke - don't fix it."

• "You've done the code analysis, you understand it, you no longer need to fix it."

What's your answer to them?

That's only the first hurdle. Here's the worst possible situation. This doesn't always happen, but it does happen with alarming frequency.

Someone in your executive foodchain will have this thought:

• "A rewrite doesn't create enough value. Rather than simply rewrite, let's expand it." The justification is that by creating enough value, users are more likely to buy in to the rewrite.

A project where scope is expanded -- artificially -- to add value is usually doomed.

Instead, do the smallest rewrite you can to replace the darn thing. Then expand to fit real needs and add value.

Answer 4

When the code has reached a point that is not maintainable or extensible anymore. Is full of short-term hacky fixes. It has lots of coupling. It has long (100+lines) methods. It has database access in the UI. It generates a lot of random, impossible to debug errors.

Bottom line: When maintaining it is more expensive (i.e. takes longer) than rewriting it.

Answer 5

If there are clean interfaces and you can cleanly delineate module boundaries, then it might be worth refactoring it module by module or layer by layer in order to allow you to migrate existing customers forward into cleaner more stable codebases, and over time, after you've refactored every module, you will have rewritten everything.

But, based on the codereview, doesn't sound like there would be any clean boundaries.

Answer 6

You can only give a definite yes to rewriting in case if you know completely how your application works (and by completely I mean it, not just having a general idea of how it should work) and you know more or less exactly how to make it better. Any other cases and it's a shot in the dark, it depends on too much things. Perhaps gradual refactoring would be safer if it is possible.