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.
Well the problem with Cringely's remarks is that the fate of Java is not strictly in Sun's hands. So no matter what you may think of Sun's efforts, it needs to be acknowledged the efforts of IBM (alphaworks), Oracle (building Java into the database), the Apache community, all the mobile phone manufacturers, countless people at JavaSigs and finally my own humble self. Each of these companies and others, each of these individuals and others all are ensuring that Java will be viable for years.
My enjoyment of programming shot up the day I discovered Java, and I have not looked back. To paraphrase: "They can pry my Java from my cold, dead hands"
Slashdot Mirror
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.
My enjoyment of programming shot up the day I discovered Java, and I have not looked back. To paraphrase: "They can pry my Java from my cold, dead hands"