Justifying Code Rewrites?

snow70 asks: "It seems that it is getting harder and harder to justify the decision to re-write rather than hack/patch away on a flawed code base, given the economic situation and the drive to squeeze every last drop out of an existing code base. Are the readers aware of any research articles or reports that extoll the benefits of re-writing in terms of the cost savings in maintenance and support ?" This topic was discussed two years ago, but I think many people who'll find themselves in this situation would also benefit from any research articles or publications as snow70 requests.

Comments

Hate to be the heretic...

[Violet Null]

But it's been my anecdotal experience that unless there's a real, justifiable reason for the code rewrite, then it's usually not worth it. Something like taking a client/server application and making it a web application requires a rewrite as a matter of course, for instance, but otherwise the costs and time tend to outweigh the benefits.

Sure, a code rewrite allows you to remove bad architectural assumptions and dump the cruft, but it also introduces the possibility of an exponentially higher number of bugs. So you've dumped a fair amount of developer work in the rewrite, and then it needs to be followed up with an even more massive amount of QA work. And, if you're actually making sweeping architectural changes, chances are very high that the new architecture will pose some unforeseen problems of it's own.

I'm not saying a code rewrite is never a good thing, but, IMHO, it's not something that should be done just because "this code is nasty" or "language X is cooler". If you can't think of a reason as to why a rewrite should be done, then it shouldn't.

It's good that rewrites are hard to justify!

[JonRock]

Point one: rewriting from scratch can be a strategic disaster.

Point two: rectifying a "flawed" code base can be done within the framework of good software engineering practice, and is a very marketable skill besides.

Things you should never do...

[metacosm]

Rewrite is one of them... Read: Things you should never do

Let me quote a little from the linked article

When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.

First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code.

A second reason programmers think that their code is a mess is that it is inefficient. The rendering code in Netscape was rumored to be slow. But this only affects a small part of the project, which you can optimize or even rewrite. You don't have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang.

Third, the code may be doggone ugly. One project I worked on actually had a data type called a FuckedString. Another project had started out using the convention of starting member variables with an underscore, but later switched to the more standard "m_". So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with a macro in Emacs, not by starting from scratch.

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

Re:Things you should never do...

[dubl-u]

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

That's true only if you don't plan to do anything differently.

I recently got called into consult on a project. They have a bunch of code. They need new features by August. Question #1 is, "Do we start over?"

The current code base mostly works, but it is complete spaghetti code. No architectural coherence, hugely inefficient, absolutely no tests, lots of copy and paste, insane use of exceptions, etc, etc, etc. My first conclusion is that the existing code is totaled.

But there isn't time to rewrite it all by the deadline and get the new features in. So we compromised with the businesspeople. Working together, we designed the new features in such a way that we touch as little of the old code as possible. Features that required modifying old code got very high estimates, so the suits deferred most of them. Further, all new code will be developed with full unit tests and functional tests, with energetic refactoring so that the architecture is solid. This gives us a good foundation to build from.

Then, after the release, we'll see what we can do with the old code. Thanks to a highly interactive estimation process (XP's Planning Game), the business people really get that touching old code is expensive. And we've also explained that hacking new stuff into existing code is throwing good money after bad; when asking for those features, they frequently ask how much of the effort can be reused. So they're almost as interested in getting rid of the old stuff as we are.

So my tips for a rewrite are:

1. Don't rewrite everything at once. Do it in a way where you can provide a stream of new releases, rewriting as you go.
2. Make the economic case for a rewrite clear. If you're getting a paycheck for this, you're obligated to help them get the best value for their money.
3. Don't do the same old thing. Figure out why the current code base sucks, and take clear steps not to repeat their errors. E.g.,
   • write unit tests and functional tests (preferrably before you write the code)
   • continuously refactor your code
   • do code reviews and design reviews (or, better, pair programming).
4. Measure the difference you're supposedly making. If your bug rates, design metrics, code metrics, reliability of hitting estimates, and performance aren't clearly better than the existing product, then maybe you're doing a rewrite for the wrong reasons.
5. Be humble. The reason the current code base sucks is that the last chumps got in over their heads. Be sure that you aren't doing the same. Remember, they probably looked at the previous old system and said, "Gosh, we could rewrite this and make it so much better!"
6. Make sure this is the last rewrite. Sure, future requirements always mean that parts of the app will be changed. But make sure the code never gets so stinky that it needs to be tossed. Every couple of months call in somebody from outside the team to review things and give you an honest checkup.

Refactor

[neitzsche]

I am a sold on the concept of refactoring instead of completely rewriting.

About four years ago, I rewrote a 15 year old device handling sub-system. It was quite horrible. The primary justification for doing it was to generate billable hours to charge the government. The secondary justification was because the old code was horrible, nightmarish and impossible to maintain.

Unfortunately, I didn't get the opportunity to redesign the legacy file structures it used. I also had to maintain 100% backward compatability. On my personal agenda was adding useful features. In hindsight, if we had used the refactoring approach the end result would probably hve been better. Certainly the beta testing would have gone smoother if it had been done in smaller increments. (Having a non-technical manager didn't help either.)

With that experience behind me now, I recommend two things to justify a major piece of work (either rewriting or refactoring):
1) Identify the current design flaws
2) Identify the features missing

These days, the only time I'm presented with a rewite opportunity is when an application is being migrated to a new platform. i.e. Web enabling a legacy app. The only applications that remain out there are still there because they are too ugly, outdated and nightmarish to maintain. So once again, I would recommend refactoring.

Don't be mad at management for being gun-shy when they hear the word "rewrite." They should be leery of a major rewrite. The end-user training costs alone can be devastating. And unless we're talking about your own personal copyrighted intellectual property, they do have a lot vesting in the old "ugly" code that they (rightly) should be scared of losing.