There are some principles of software development that were described by M. Lehman by observing large-scale development teams (such as IBM’s OS/360 development in the 1960s). When you put several of these principles together, it is not very encouraging for those of us who are concerned about software quality.
1. Early bug rate predicts late bug rate
You would think that if you fix a lot of bugs early in the project, you could expect to have a lot fewer bugs later. In fact, observation shows that projects that have (and fix) an above-average number of bugs early tend to have above-average bug rates later.
2. Software grows over time
As users demand more features and functions in their software, the size and complexity of a released software package tend to grow.
3. Bugs are introduced when bugs are fixed
No matter how careful we are, sometimes we introduce bugs while we are fixing others. As long as the ratio of bugs-introduced to bugs-fixed is low, working on bug-fixing is a productive enterprise.
When you combine these observations, things get stickier. For example, the ratio of bugs introduced to bugs fixed tends to get larger as the software package gets larger. As a result, bug-fixing gets less and less efficient as time goes on because of the growth of the software.
Also, we can imagine that putting a major push on early bug-fixing in project could drive up the introduced-to-fixed ratio, thereby keeping the first rule valid – we’ll find even more bugs later.
What’s an Agile manager to do?
First of all, pay attention to bug-find rate and system size and complexity. My guess is that having the software developers fix their own bugs before QA sees the software doesn’t fall into the domain of the first rule. In any case, it’s a good thing to have a designer/implementer see exactly what went wrong – it’s a good opportunity to correct one’s thinking. Of course, Agile principles suggest that pair-programming does exactly this at the earliest possible moment in the coding process.
Second, always strive to reduce complexity, whether by simplifying the model, partitioning the system, or adapting to existing services rather than inventing new ones.
Finally, make sure that your teams are relentlessly refactoring the code. The teams always learn better and better ways to streamline and simplify the functions they’ve already implemented, so don’t hold back on letting them express that knowledge.
If you want to read more on how software evolves over time, do a search on “Lehman software evolution” and see what’s been learned.
____________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info at http://johnlevyconsulting.com
1. Early bug rate predicts late bug rate
You would think that if you fix a lot of bugs early in the project, you could expect to have a lot fewer bugs later. In fact, observation shows that projects that have (and fix) an above-average number of bugs early tend to have above-average bug rates later.
2. Software grows over time
As users demand more features and functions in their software, the size and complexity of a released software package tend to grow.
3. Bugs are introduced when bugs are fixed
No matter how careful we are, sometimes we introduce bugs while we are fixing others. As long as the ratio of bugs-introduced to bugs-fixed is low, working on bug-fixing is a productive enterprise.
When you combine these observations, things get stickier. For example, the ratio of bugs introduced to bugs fixed tends to get larger as the software package gets larger. As a result, bug-fixing gets less and less efficient as time goes on because of the growth of the software.
Also, we can imagine that putting a major push on early bug-fixing in project could drive up the introduced-to-fixed ratio, thereby keeping the first rule valid – we’ll find even more bugs later.
What’s an Agile manager to do?
First of all, pay attention to bug-find rate and system size and complexity. My guess is that having the software developers fix their own bugs before QA sees the software doesn’t fall into the domain of the first rule. In any case, it’s a good thing to have a designer/implementer see exactly what went wrong – it’s a good opportunity to correct one’s thinking. Of course, Agile principles suggest that pair-programming does exactly this at the earliest possible moment in the coding process.
Second, always strive to reduce complexity, whether by simplifying the model, partitioning the system, or adapting to existing services rather than inventing new ones.
Finally, make sure that your teams are relentlessly refactoring the code. The teams always learn better and better ways to streamline and simplify the functions they’ve already implemented, so don’t hold back on letting them express that knowledge.
If you want to read more on how software evolves over time, do a search on “Lehman software evolution” and see what’s been learned.
____________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info at http://johnlevyconsulting.com
No comments:
Post a Comment