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

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.

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 program on a laptop, while in the car heading to the install site!)

I found the comments of the first few posters to be insightful, but there's at least one situation they overlooked - what if the code is crummy for perhaps the most common reason of all: insufficient time combined with constantly changing requirements? In that case, given time to really do things right could make a difference. Taking the pressure off lets you actually design BEFORE you code, instead of doing them in parallel, and you might even get to shift some of the user interface planning off onto someone qualified to do it... (I've never had the pleasure of working within a team on a project, BTW, so YMMV. Oh, and I've never had the pleasure of working on a project where there was anybody to say "no" to the customer's latest wacky, impractical, last-minute ideas...)

OK, where were we - oh yes, I'd like to hear the answer to the poster's question too.