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.

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.

Re:Hate to be the heretic...

[sporty]

It depends on the scale of the rewrite. Rewriting your OS would suck. Rewriting a single library and fixing things via refactoring methods.. it's not that bad.

-s

Re:Hate to be the heretic...

[wik]

Until you have to replicate the bugs from the old library. Have fun!

Re:Hate to be the heretic...

[Rick the Red]

I've found it's best to use new library function names. If you re-write an existing function, then as you say you must replicate the bugs. If you use a new name, you can slowly migrate code to the new functions while still using the old functions. I know of one commercial product that introduces any new function into their production library one release before they start calling it, just to ensure that having it there doesn't break anything. After two or three releases they've finished their migration, but

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 [catb.org]

Re:Cathedral and the Bazaar

[perljon]

This is why a simple modeling technique is so valuable. I use a simplified version of UML to model my application at different levels of design. This allows me to work out the problem in arrows and pictures instead of in code. Although, it is quite tedious, by the end of a couple of weeks, you can go straight to version 2 of your software. (Where it would take you 2 weeks to model, it might take you a year or 3 to get to version 1. I'd rather spend a few weeks.)

The drawback to this approach is of course

It's good that rewrites are hard to justify!

[JonRock]

Point one: rewriting from scratch can be a strategic disaster. [joelonsoftware.com]

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

Re:It's good that rewrites are hard to justify!

[jpkunst]

Point one: rewriting from scratch can be a strategic disaster. [joelonsoftware.com]

Well, that article is from 2000 and the example that he gives is that is was obviously a bad decision for Netscape to start over from scratch after version 4. But is that still so obvious in 2003? Thanks to that decision, we now have the Gecko rendering engine, Mozilla and all its derivatives, so maybe it wasn't such a bad decision after all to rewrite from scratch?

JP

Re:It's good that rewrites are hard to justify!

[Cuthalion]

Gee, it only took them like 5 years. Could they have made Netscape better in 5 years without starting over from scratch, during which time they lost the browser war and were acquired by AOL? Is Netscape, as a company, successfull?

I would say the answer is no.

Re:It's good that rewrites are hard to justify!

[The Cydonian]

But that's only one example of a re-write failure. Opera, if I remember correctly, has completely rewritten its code base for its latest version.

Re:It's good that rewrites are hard to justify!

[Etyenne]

Netscape (actually, Mozilla) rewrite from scratch may have been a disaster from a commercial POV, but from a technical one it is a great success. Personnally, I don't care about the browser war or market share, I care about quality software. That is what OSS is about. Mozilla > 1.0 is quality software. They could have refactored the cruft of Netscape 4 but it is open to debate if they would have had a result as good.

jwz criticism of the Mozilla project in 1998 may have been justified. Joel rant on

Refactor

[MountainLogic]

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

Re:Refactor

[__past__]

As you say, refactoring relies on having good tests in the first place. Probably a code base that needs a rewrite hasn't been developed test-first up to now, or even in a test-friendly fashion, so that's a huge problem - coming up with good tests after the fact is a lot of error-prone (and boring) work.

It's probably still a better idea than to start from scratch, though. I seem to remember that someone announced a book on this subject (adding tests for legacy code) on the XP or test-driven mailing list, m

Re:Refactor

[4of12]

Yeah...sounds suspiciously like Extreme Programming to me.

And, AFAICT, that's tantamount to constant rewriting.

The assumptions are valid, though. Namely,

software is always improvable.

Whether it will actually improve under applied effort is another matter.

If you take the XP approach, then refactoring even at even the highest levels may be justifiable, and if you write in "refactoring" into your XP code dev plan from the get go, then you won't have to write a special, rejectable, proposal for "rewrite

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 [joelonsoftware.com]

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.

If the

[geekoid]

author looked at the code I inherited, he would change his point of view.

We got a function thats 16 hundred lines long(not countinf white space and comments), it has 5 goto's.

The person who wrote the code was a self taught programmer. the next person was a self taught programmer with no experience in the language.

The use 3rd part controls that leak like a sieve.

there is redundant code all over the place. Comments are lacking.
there is stuff like:

If (X = 1) and (X = 1) then

and stuff like

while .eof

But.....

[samael]

I'd say that the right thing to do (to start off with, anyway) is to refactor, not scrap it.

Take that 1600 line procedure and rewrite it more sensibly (modular, no gotos, break it into dozens of smaller procedures). Then do the same with the rest of the code. Remove duplication as you go through. You'll constantly have a system that works and is testable and you'll be able to reverse-engineer the spec as you go through.

If you tried to rewrite it from scratch, you'd have to analyse the whole thing to se

Re:Things you should never do...

[ClosedSource]

Any kind of advice that says "Always do.." or "Never do.." is going to be wrong at least some of the time. To state the obvious: not all situations are the same, so you can't treat them as if they were.

One reason you might want to rewrite a program from scratch is if the effort to understand the code is significantly greater than the effort to understand the problem you're trying to solve. Of course, requirements are an important part of the analysis. If legacy behavior is a requirement (which will typical

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.

Re:Things you should never do...

[WolfWithoutAClause]

Pretty much agreed; although rewrites of systems can work well in some well-contained cases.

Generally, In coding (and life in general) problems fall into roughly two categories:

a) messes inherent in the problem domain

b) messes you caused whilst solving the problem in the way you did

Trouble is, most software engineers aren't real good at telling the difference between the two, and usually prescribe 'rewrites' for both of them. If the mess is type b) then you may be able to remove it, albeit often caus

Sunk costs

[Dr. Photo]

Some managers will disingenuously try to use "Return on Investment" to retroactively justify past spending decisions, without regard to whether trying to salvage a poor decision is a cost-effective use of current and future investment.

ROI should be used as a measure not of how far you've gone, but rather how close you are to your current goal.

As an example which anyone reading /. will appreciate: Imagine you've spent 8 hours downloading a huge file over dialup, and it's 80% complete... and during that time, your friendly local Telco person has arrived and installed a DSL line that could download the same file in under an hour.

Which, then, is the better use of your time: to wait two hours for your current download to complete, or to ditch it for the one hour download?

Of course, as a precaution you might let the slow download continue in case the faster line doesn't work right, just as a company could keep the existing model in operation as a prototype of the new system is developed...

Companies that can't see this, or that foster a corporate culture in which ROI is used as a retroactive cover-your-ass rather than as an estimate of future costs and benefits, will in the long run be easy pickins for their more nimble-minded competitors.

it's not so much the rewriting

[jilles]

If you can make a business case for rewriting an existing piece of software, any sane project manager should go for it. The whole problem is that most programming still happens based on hunches & gut feelings. If there's too much money like before the .com crisis, you can afford to aimlessly optimize pieces of code like that and get away with it. However, in the current economic situation, people are not handing out money anymore. You have to convince people to do so.

Delivering a piece of code on time with the desired level of quality still boils down to black magic in many organizations. A large percentage of software projects either fails or delivers something different than was intended.
People have noticed this and telling them that you'll lock yourself up, hack away for a couple of weeks and maybe something good will come out does not do the trick anymore. They simply do not trust you to deliver what you claim you can deliver anymore.

Of course that doesn't mean you shouldn't rewrite code. You should however, make more of an effort to provide evidence to the relevant people that a) there is a problem with the code that should be fixed (e.g. bugfixes take an unusual amount of resources on that part of the code) b) you have a plan for resolving this problem (e.g. spending two weeks on refactoring) and c) this plan is cost-effective (this is the hard part).

I've seen a project where it was calculated that fixing the outstanding 100 or so bugs for a component (serious bugs) would cost a certain amount of money. This process was likely to introduce more bugs of the same serious nature (given experience with maintaining this component). An alternative was to redesign and reimplement the offending component, a plan was made to do so and it was approved because executing the plan was shown to be more cost effective than continuing to maintain the old component. The plan was executed and the new component has so far proven to be more reliable and maintainable.

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.

Re:Refactor

[Mr.Locke]

Martin Fowler has a very comprehensive book on refactoring - Refactoring: Improving the Design of Existing Code [martinfowler.com] (On Amazon [amazon.com])

Typical geek. Focus on the business problem.

[(H)elix1]

I'm not going to touch the refactor/rewrite issues, because the fundamental problem is you are not effectively giving yourself enough time to do whatever the hell you want to do. Take what time you think it will take to implement something, double it, and round up to the next unit of measurement. Odds are the business does not give a rat's ass about the wrong or right way to implement something anyhow. Why confuse them with options?

How long will it take to fix this? (keep the snicker internal) Two weeks...

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.

Do you have time?

[bscott]

I'd like to rewrite most of the projects I've worked on, especially one in particular which gets used and re-worked year after year. A ground-up reworking of the code would make future changes hugely easier, but instead we spend vastly more time trying to force more cruft on top of the massive pile of cruft and hoping it'll work. Even when we start six months before the usual time-frame, we always - ALWAYS - end up making modifications right up to the time it goes live. (I've actually had to recompile a

Re:Do you have time?

[hswerdfe]

sigh....I had to Call the office from on site to get a recompile and have someone ftp it to me, because the install failed....our company sucks...we have NO qa department...

Re:Do you have time?

[dubl-u]

insufficient time combined with constantly changing requirements? In that case, given time to really do things right could make a difference.

Every project I've ever been on has insufficient time combined with changing requirements. I'm not even sure if I've heard of a project where that wasn't the case.

Given that, I think it's our responsibility to create the necessary space to do good work. Now I only offer clients two options. One is building 100% solid software. The other is building cheap, throwawa

Re:Do you have time?

[bscott]

> Every project I've ever been on has insufficient time
> combined with changing requirements. I'm not even sure
> if I've heard of a project where that wasn't the case.

I had one, once... fond memories! I actually had all the time I needed and a fairly clear goal. There was even left-over time in the budget to do a second version with some nice new features that the users decided might come in handy down the road. I even was able to write user-level documentation as well as technical docs for an

How much pain can you tolerate?

[pmz]

Brooks' The Mythical Man Month reads "...plan to throw one away; you will, anyhow." However, I read this to mean a real working prototype rather than a production system that simply gets tossed. If you are wondering whether a genuine production system needs rewriting, it's probably too late. If you can tolerate the pain, factor where you can; if not, brave the job market for a better opportunity.

Re:How much pain can you tolerate?

[geekoid]

most production code is a prototype that was 'good enough' and 'we don't want you to have to do the same thing twice' and 'well, the developer finished the prototype, so the production model should be ready in a weak'

Re:How much pain can you tolerate?

[pmz]

most production code is a prototype that was 'good enough'...

Yeah, I've seen this happen myself. The end result was rather unsavory in the long run. A lot of the problem with software development is that few people look past the next milestone.

A third way

[Waffle Iron]

The refactor vs. rewrite argument never ends. However, there is something inbetween the two that I've found useful from time to time: go to all of your source files and comment out all of the code except "main()"; make sure it still builds and executes. Now, start adding back functionality one piece at a time, redoing the parts that need major rework.

This way, if you're rearchitecting big sections, you don't have to worry about keeping bidirectional compatiblity during the conversion. This approach also w

don't rewrite, refactor

[aminorex]

If a codebase is sufficiently complex and mature
so that rewriting raises business issues, you're
almost always better off incrementally refactoring.
Take one bug at a time, and resolve it by improving
design, rather than by adding layers of cruft.
Formulate end-design goals, and work towards them
incrementally, preserving all current correct
behaviours.

Yes, it takes longer than rewriting, in order to
achieve 90% of the end goal, but the last 10% is
always the deal maker or breaker. If your
codebase is decrepit and

rewriting rules!

[rodolfo.borges]

if it's worth to write, it's worth to rewrite

To Clarify...

[snow70]

Actually I am talking about refactoring in this context, a targetted re-write of a core of the application to deliver scalability and stability that the existing 'design' simply doesn't deliver. We are talking about less than 10% re-write, whilst keeping everything that the customer is used to seeing in terms of logs, O&M management etc. However it seems there is little hard evidence to support this process, which to me seems so natural.

Speaking of refactoring ...

[gerddie]

you might be interested in this book: Refactoring: Improving the Design of Existing Code [amazon.com]

Clarke's third law of software design

[scrod]

Any sufficiently patched-up code base is indistinguishable from magic.

Rewrite Experience

[CyberGarp]

My first project out of college was to "patch" some computer software. It was written by three different engineers in FORTRAN, working for about 2 years. When it started crashing all the time, the solution was to put a watchdog on the computer. Then it would loose the state of computation, so it started saving it's computation state regularly, and upon booting would restore it. Eventually it saved the state that led to a crash, at which point it started rebooting like a yoyo.

Looking over the software, it was a total mess. Every section of the code completely reordered all data on the stack, going several levels deep. I asked what the formula the code was trying to compute, and was shocked to see a simple iterative formula, with about 10 variables. I recommended a rewrite. I was heckled.

I was eventually given one month to waste, before they said I would be forced to patch the existing code. The first thing I did was remove the watchdog. Then I did a data flow diagram and found a straight line. No control over the format of the data going out, but total control of coming in. So presto, I structured the data coming in to match the required format of the output. It would all sit in place and the routines would work on it like a pipeline. It went from taking four or five minutes to do a single pass to nine seconds. It also didn't crash all the time. The size of the code shrank dramatically.

Two other times in my career I've ran into similar code. The next was about two hundred pages of FORTRAN, that I replaced with one page of lex.

The next time was a database engine written in FORTRAN by an engineer with no database theory (data/indices mixed, every index was of a different form, every violation of normalization you can think of, etc). I recommend a rewrite then, and just about got fired, because the VP wrote the code. It wasn't rewritten and their competitors have just about squeezed them out of the market, because they can't adapt.

Lesson: FORTRAN written by engineers is generally in bad need of a rewrite.

Re:Rewrite Experience

[panda]

I've had similar experiences.

In one case, a project manager came to me two days before his deadline and said, "Can you look at this? So-and-so was working on it, and it won't run. We think it's there, and it probably just needs a little tweak to get it running."

Sure, I looked at the code. Turns out what I was looking at was a "translation" of a COBOL app that ran on the mainframe to another programming language that would run on the new UNIX server. The translation was a big, tangled ball of string, actua

Re:Rewrite Experience

[aaaurgh]

I used to wonder what was so holy about a silent night, now I have a child.

Amen to that!

Plan to throw one away...

[Grey Haired Luser]

You will anyway

Fred Brooks.