Defects are for Losers
Defects are for Losers
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
A developer is responsible for using any and all techniques to produce defect free code. The average developer does not take advantage of all of the following opportunities to prevent and eliminate defects:
- 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
Like the 'rinse and repeat' process on a shampoo bottle, this process is repeated until the code is cleaned or until you run out of time and are forced to deliver.
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.
Just like the roads that we use have highways, secondary roads, and tertiary roads -- DbC can be used on those highways and secondary roads to catch incorrect conditions and stop defects from being detected far away from the source of the problem.
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%
Of all the techniques mentioned above, the most potent pre-debugger technique is inspections. inspections are not sexy and they are very low tech, but the result of organizations that do software inspections borders on miraculous.
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
During Unit TestingDevelopers 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%
ConclusionOverworked 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
ReferencesGilb, Tom and Graham, Dorothy. Software Inspections
Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
Published at DZone with permission of Dalip Mahal , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.