Code does decay... (Score 2, Interesting)

I do agree with you that a lot of developers spend time rewriting code not to make it better but rather just to make it different.

However, I have to take issue with your position that rewriting code is bad because it throws out all the bug fixes that past programmers spent time and effort finding and fixing. I suggest reading an article in IEEE Transactions on Software Engineering 1/2001 issue. "Does Code Decay?" I would like to post a URL to that article .. but unfortunately it requires payment.

Eick, et al's conclusion was that indeed code does decay. Their definition of decay was "A unit of code is decayed if it is harder to change than it should be, measured in terms of effort, interval, and quality." (italics theirs) The source of their data was the entire change history of a 15-year old real-time software system for telephone switches with over 100 million lines of code. What they did is measure the number of files that a single change had to modify. What Eick found was that once the initial development flurry of activity died off the probability of a change needing to result in modifying more than one file was less than 2%. Within five years the probability had increased to greater than 5%. It is Eick's contention that this is a sign of code decay because the number of "simple" changes was dropping and the number of complex, involved changes was increasing.

Furthermore, they found that modules began to exert "gravitional" effects on nearby modules. This resulted in blending and stronger and stronger coupling of the modules.

They listed a number of causes of decay:

• Inappropriate Architecture
• Violations of the original design principles (The program is required to do something that was not anticipated at design time)
• Imprecise requirements
• Time pressure
• Inadequate programming tools
• Organizational Environment (low morale, high turnover, poor inter-developer communication)
• Programmer variability (some code that should only be touched by experts is mucked up by novices.)
• Inadeqate change process

Bad management of course will magnify the issue.

To that list I would also add that as the field matures we learn better and better techniques. A very good example of this was the seachange that I saw when the use of exceptions were first introduced. I remember all the effort of trying to communicate an low-level error condition up to the calling chain. Error codes return values -- what a nightmare! Once I saw exceptions and understood them -- It made the quality of my code much, much better.

So to Eick's list I would add general advances in the field result in the realization that what was previously considered "best" practice is no longer the case. This happens in every scientific field and computer coding is no different.