Feature Driven Development

De Luca on FDD Newsletter Issue 5

Testing is one of the Least Effective Defect Removal Techniques

Over the years I've observed several reasons for this. One reason is the fear people have of their work being inspected. Thus setting the inspection culture correctly is a critical success factor. Another reason is related to pre-object oriented systems where you get a request like "here's a 500 page COBOL program, we're going to do an inspection on it in 3 days." It's just too big. Thus ensuring inspections are performed on the right artifacts, at the right level of abstractions, and the artifacts are at an appropriate granularity are all critical success factors.

In well designed object oriented systems, functions are provided by the collaboration of classes and the methods they call on each other. We model this using the UML sequence diagram and the granularity and abstraction of FDD features especially helps here.

In most cases, a sequence diagram will only have 3-5 classes in it and the typical shape is that the first two calls are simply delegating down, and then there's a bit of work in the right hand classes and possibly some kind of accumulation or checking done back near the sender. Thus, the UML sequence diagram for an FDD feature, and then the code in each class to implement that feature, is a very small piece of work (tiny compared to monolithic programming). Furthermore, every FDD feature directly represents a client-valued function. These aspects mean that FDD delivers the right artifacts at the right abstractions and of the right granularity.

Inspections are one of the most effective defect removal techniques. Inspections complement other QA techniques and they are an important milestone for meaningful progress and risk reduction.

Some facts about inspections:

• 55% of maintenance changes in error before inspections. After 2%. Freedman, Weinberg, 1982.
• Before inspections 4.5 errors per 100 lines of code. After 0.82 errors per 100 lines of code. Freedman, Weinberg, 1982.
• Aetna Insurance found 82% of errors using inspections and decreased resources by 25%. Fagan, 1976.
• AT&T 14% increase in productivity and 90% decrease in defects. Fowler 1986.
• Inspections find different kinds of errors than testing does. Myers 1978. Basili, Selby, Hutchens 1986.
• Combination of design and code inspections removes 60-90% of all defects. Fagan 1976.
• Reducing the number of defects improves development time.
• If you know your work will be inspected, you are more careful with it (programmers write their code differently if they know someone else is going to read it).

Table 1 Defect Removal Methods. Capers Jones, 1996.

This is more than just defect removal. Inspections are a fantastic culture and team-building activity and they actively complement the feature team and Chief Programmer-oriented structures in Feature Driven Development. FDD applies inspections to both the design (in Design By Feature) and the code (in Build By Feature).

Inspections make it so much easier to propagate team culture, syntactic and semantic standards, naming standards, process, and so on. Programmers learn to improve their work (design and code) through participating in inspections.

Inspections, like many things, need to be introduced in a way that removes fear from a programmer. Programmers generally don't like to be told they did something wrong, or could have done it better. Setting the inspection culture is key so that these fears are removed and everyone sees them as a great learning tool as well as a quality tool. You should not micro-manage and use inspections as some kind of punitive measurement tool for your programmers.

However, to only list these two reasons thus far is to suggest that despite the evidence - the measured effects of inspections - people don't inspect due to the fear programmers have of their work being inspected and due to the size of the design or code to inspect. This is misleading as most people aren't aware of the evidence in the first place. As is the case for so many of the problems in I.T., the solutions have been identified long ago.

Inspections are also a time to market (or time to deployment) tool. That is, less defects means faster projects. However, a common knee-jerk reaction is that "inspections are taking too much time, so to speed up, we are going to stop inspecting." This is a false economy. It might appear that you are speeding up, but in fact you aren't. All you are doing is trading the appearance of different kinds of work - and in doing so, the total project time is being lengthened.

By not inspecting, and therefore doing only coding, what people are doing all the time is coding. Coding is incorrectly connected to "getting it done" and therefore by doing this all the time, things must be going faster. It is an appearance and it is an illusion in total project terms.

Inspections, however, are not coding. People are in a room - without keyboards, and screens, and compilers, and editors. The inspection itself takes time. Time that would otherwise be spent coding.

The issue here is that of connecting the act of coding with real work and fastest progress. There is no mystery here. This has been measured many times before. More code does not equate to fastest progress; correct and standards-conforming code does. Inspections speed you up, not slow you down. Understanding this common mental model can help you "get over it," help those around you "get over it," and allow you to see through the misleading appearance of "always coding."

Feature Driven Development directly facilitates the implementation of known best practices such as design and code inspections by delivering the right artifacts, at the right level of abstractions, and of the right granularity, and also by directly implementing team structures that map to these artifacts and that promote the mentoring and team building aspects of inspections.

With thanks to the review team: Gavin Baker, Phil Bradley, David Bye.