Software: maintenance vs new development
July 5, 2006
This topic has been on my mind for awhile now. My current position has me doing about 95% maintenance on existing code. While I enjoy the challenge, the work is often frustrating. The optimal solution to any problem is never an option due to time constraints. This mirrors ‘new development’ as well, because business concerns/timelines/budgets rule new development as well. I’m not under any illusion that there’s a difference there. However, most of the problems encountered which are requiring fixes exist solely because of poor coding decisions by previous developers. Had the project been designed with even a modicum of flexibility, most of the problems would be extremely quick fixes. Instead, fixes which should take hours sometimes take days. And even when the problems are ‘fixed’ they are still often not even close to being optimal.
Short question - at what point is it better to scrap a project and start over with the benefit of the experience and hindsight from the previous codebase? Some people may say ‘never’, but I’m not really a believer in that idea. Can anyone convince me otherwise? Any experiences you’d care to share on this subject?
Posted in Business, Development, MySQL, PHP, Uncategorized, linux, opensource
July 11th, 2006 at 4:23 pm
In the book “Facts and fallacies of software engineering”, Robert Glass touches on this:
“Fact 19:
Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.”
Basically it boils down to this: It is difficult to modify software. It’s a recommended read.
July 11th, 2006 at 5:47 pm
I couldn’t remember where I’d read that before, but I have read the 25% rule in the past. I think I took it out of context and was applying it to entire systems, but this seems to specify this rule only/just at the component level. Does this same rule hold true at a macro level too?
Thanks for the comment!