- Before the code is written
- As the code is written
- Writing mechanisms for early detection
- Before the code is executed
- During unit testing
- After the code is tested
The technique that is used most often is #6 above and will not be covered here. It involves the following:
- Code is delivered to the test department
- The test department identifies defects and notifies development
- Developer's fire up the debugger and try to chase down the defect
The almost ubiquitous use of #6 leads to CIOs and VPs of Engineering assuming that the metric of one tester to two developers is a good thing. Before assuming that #6 is 'the way to go' consider the other techniques and statistical evidence of their effectiveness.
Before the Code is Written
How much of an effect can planning have? Two methodologies that focus directly on planning at the personal and team level are the Personal Software Process (PSP) and the Team Software Process (TSP) invented by Watts Humphrey.
PSP can raise productivity by 21.2% and quality by 31.2%
TSP can raise productivity by 20.9% and quality by 30.9%
Not only does the PSP focus on code planning, it also makes developers aware of how many defects they actually create. Here are two graphs that show the same group of developers and their defect injection rates before and after PSP training.
- Decision tables
- Proper use of exceptions
As the Code is Written
Test Driven DevelopmentTest driven development (TDD) is advocated by Kent Beck and stated in 2003 that TDD encourages simple designs and inspires confidence. TDD fits into the category of automated unit testing.
Automated unit testing can raise productivity by 16.5% and quality by 23.7%
Writing Mechanisms for Early Detection
Design By ContractOne way to build checkpoints into code is to use Design By Contract (DbC), a technique that was pioneered by the Eiffel programming language It would be tedious and overkill to use DbC in every routine in a program, however, there are key points in every software program that get used very frequently.
Clearly very few of us program in Eiffel. If you have access to Aspect Oriented Programming (AOP) then you can implement DbC via AOP. Today there are AOP implementations as a language extension or as a library for many current languages (Java, .NET, C++, PHP, Perl, Python, Ruby, etc).
Before the Code is Executed
Static AnalysisMost programming languages out there lend themselves to static analysis. There are cost effective static analysis for virtually every language.
Automated static analysis can raise productivity by 20.9% and quality by 30.9%
The power of software inspections can be seen in these two articles:
Design inspections can raise productivity by 16.9% and quality by 24.7%
From the Software Inspections book on p.22.
In one large IBM project, one half million lines of networked operating system, there were 11 development stages (document types: logic, test, user documentation) being Inspected. The normal expectation at IBM, at that time, was that they would be happy only to experience about 800 defects in trial site operation. They did in fact experience only 8 field trial defects.Evidence suggests that every 1 hour of code inspection will reduce testing time by 4 hours
Developers have learned that improving code and getting rid of code "smells" can be accomplished through refactoring. Unknown (or untrusted) by developers is the idea of using automated refactoring tools.
Automated refactoring can raise productivity by 8.0% and quality by 11.7%
Manual refactoring can raise productivity by 4.3% and quality by 6.7%
Overworked developers rarely have time to do research, even though it is clear that there is a wealth of information available on how to prevent and eliminate defects. The bottom line is that if your are only using technique #6 from the initial list, then you are not using every technique available to you to go after defects.
My opinion only, but:
A professional software developer uses every technique at his disposal to prevent and eliminate defects
Want to see more sacred cows get tipped? Check out
- Comments are for Losers
- Efficiency is for Losers
- Debuggers are for Losers
- Testing departments are for Losers
Gilb, Tom and Graham, Dorothy. Software Inspections
Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.