Slashdot Mirror
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.
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
"I'll say it again for the logic-impaired." -- Larry Wall.
Yeah...sounds suspiciously like Extreme Programming to me.
And, AFAICT, that's tantamount to constant rewriting.
The assumptions are valid, though. Namely,
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 from scratch".
Anyway, the usual motivation for doing The Re-Write has to be when some typical lurking maintainance or debugging chore, or "small feature enhancement" takes a helluva a lot longer than the decision makers like. Sometimes, Joe's a bad programmer is the reason it took so long; other times, it's because Joe was handed a plate of spaghetti masquerading as code.
If you can say, truthfully, that those exact same debug/feature enhancements would have cost x% less if done within the framework of the hypothetical rewritten code base of the future, then money allocators will do the amortization and figure out if it justifies the expense.
I'd wildly guess the rewrite shouldn't cost more than about 3 times what annual debug/support/maintenance costs. Others here may know better, though.
"Provided by the management for your protection."
I have a pretty good formula for getting the actual time it will take :
...' : 3 months minimum, 18 months average.
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
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.
Glonoinha the MebiByte Slayer
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 causing different (hopefully fewer) kinds of problems. If the mess is of type a) then it implies that the engineers have missed it; which nearly always leads to trouble in the long run...
If it's the original team that is involved, a rewrite might be a good idea, but usually it isn't the original team; and even if it is the original team there is a thing called 'second system syndrome' where the designers try to fix every, single, little problem in their first attempt; this usually ends up in a system too large and unwieldy to work well.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"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.
I used to wonder what was so holy about a silent night, now I have a child.