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.

Cathedral and the Bazaar

[PeekabooCaribou]

From The Cathedral and the Bazaar, by Eric S. Raymond:

"... To put it another way, you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once [JB]."

Portions of that quote are borrowed from The Mythical Man-Month. More is available online

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.

Refactor

[MountainLogic]

Refactor, don't rewrite! First write unit & functional tests then start refactoring.

not B&W

[NanoGator]

Sorry to say this, but we don't live in a perfect world. As long as management bases their timelines on when the next trade show is coming up, we're not going to see rewrites happen until one of these deadlines is very badly missed. The people in charge just plain don't care about flawed or badly maintained code bases. They're concerned with getting a product that meets the promises that Marketing made. Sadly, engineers are too good at working within their limitations, thus making rewrites not all that necessary. (As in "we can't launch unless we do that" necessary.)

I don't think finding articles that show off the wonderfulness of code rewrites will be useful at all. Instead, this topic needs to be made attractive to PHBs out there. Make "total rewrite" a buzzword (you know, like e-commerce, push technology, and multi-media) and you'll gain a lot more leverage than landing a report labeled FYI on your boss's desk. Make it fashionable.

You all may thing I'm being cynical or even sarcastic, but I've spent the last 6 years watching PHB's work. I've listened to some bizarre rationale. I understand enough about how they work that I could become a cartoonist. I'll be happy to carry the torch when Scott Adams retires.

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.

How long will it take?

[Glonoinha]

I have a pretty good formula for getting the actual time it will take :

If your coder is just out of school take any time estimates and factor by x5 Estimates two days, it will take him two work weeks. (*)

Junior programmer with 1-2 years experience on this kind of thing - factor by x4.

Senior programmer with half a decade or more of experience = factor by x2 or x3 - it varies.

Any task with a description that starts 'Why don't you just ...' : 3 months minimum, 18 months average.

Manager says 'It can't be done.' - it will be done by Monday.

(*) - the reason the Junior guys do this is the estimate how many hours it will take them to complete (which is generally half the number it will actually take) and the math in their head assumes 24 hours of productive time in a day until they finish it. They -could- finish in two days, but they are not going to actually finish in two days. Senior guys recognise that they only get 5 productive hours in a day (on a good day) and divide the number of hours they think it will take by 5 to get days. Of course they also take twice as many hours to get it done, hence the 2x factor for them.