Wednesday, 24 April 2013

Defects are for Losers

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:
  1. Before the code is written
  2. As the code is written
  3. Writing mechanisms for early detection
  4. Before the code is executed
  5. During unit testing
  6. 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:
  1. Code is delivered to the test department
  2. The test department identifies defects and notifies development
  3. 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
Before writing code, a developer has the most options available to him. The developer has an opportunity to plan his code, however, there are many developers who just 'start coding' on the assumption that they can fix it later.

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.
Before PSP training
After PSP training
The other planning techniques are:
  • Decision tables
  • Proper use of exceptions
Both are covered in the article Debuggers are for Losers and will not be covered here.


As the Code is Written
Many developers today use advanced IDEs to avoid common syntax errors from occurring   If you can not use such an IDE or the IDE does not provide that service then some of the techniques in the PSP can be used to track your injection of syntax errors and reduce those errors.

Pair Programming

One technique that can be used while code is being written is Pair Programming.  Pair programming is heavily used in eXtreme Programing (XP).  Pair programming not only allows code to be reviewed by a peer right away but also makes sure that there are two people who understand the code pathways through any section of code.

Pair programming is not cost effective overall (see Capers Jones).  For example, it makes little sense to pair program code that is mainly boiler plate, i.e. getter and setter classes.  What does make sense is that during code planning it will become clear which routines are more involved and which ones are not.  If the cyclomatic complexity of a routine is high (>15) then it makes sense for pair programming to be used.

If used for all development, Pair Programming can raise productivity by 2.7% and quality by 4.5%

Test Driven Development

Test 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
Defects are caused by programs either computing wrong values, going down the wrong pathway, or both.  The nature of defects is that they tend to cascade and get bigger the further in time and space between the source of the defect and the noticeable effects of the defect.

Design By Contract

One 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 Analysis

Most 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%


Inspections

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.

The power of software inspections can be seen in these two articles:
Code inspections can raise productivity by 20.8% and quality by 30.8%
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 Testing
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%

Conclusion
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

Other articles in the "Loser" series
Moo?

Want to see more sacred cows get tipped? Check out
Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)

 References
Gilb, Tom and Graham, Dorothy. Software Inspections

Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
Posted by at No comments:
Labels: , , , ,
Subscribe to: Posts (Atom)