Reducing defect injection rates in large software development projects

Question

In most software projects, defects originate from requirements, design, coding and defect corrections. From my experience the majority of defects originate from the coding phase.

I am interested in finding out what practical approaches software developers use to reduce defect injection rates.

I have seen the following appraoches used with varying levels of success and associated cost

• code inspections
• unit tests
• static code analysis tools
• use of programming style
• peer programming

Answer 1

First, bugs injected at requirements time are far, far more costly than coding bugs. A zero-value requirement, correctly implemented is a piece of zero-value, unused (or unusable) functionality.

Two things reduce the incidence of bugs

• Agility. You are less likely to inject bugs at every step (requirements, design, etc.) if you aren't doing as much in each step. If you try to write all the requirements, you will make terrible mistakes. If you try to write requirements for the next sprint, odds are better that you will get those few requirements correct.

• TDD. You are less likely to struggle with bad requirements or bad design if you have to write a test first. If you can't figure out what you're testing, you have a requirements bug. Stop coding. Step away from the keyboard.

  If you can't figure out how to test it, you have a design bug. Again, stop coding. Fix the design so it's testable. Then move forward.

Answer 2

I think the main problem of injection rates can become from a lot of sources, and it vary from environment to environment.

You can use a lot of best practices like TDD, DDD, pair programming, continuous integration, etc. But you will never be free from bugs, because what creates bugs are human people, and not exactly the processes.

But IMO, using a bug tracker tool could bring you hints of which problem is more recurrent. From there, you can start attacking your main problem.

Answer 3

In my experience it has been the fault of the process, not developers, that permit defects. See They Write the Right Stuff on how the process affects bugs.

Competitive Testing

Software developers should aspire to prevent testers from finding issues with the software they have written. Testers should be rewarded (does not have to be financial) for finding issues with software.

Sign Off

Put a person in charge of the software who has a vested interest in making sure the software is devoid of issues. The software is not shipped until that person is satisfied.

Requirements

Avoid changing requirements. Get time estimates from developers for how long it will take to implement the requirements. If the time does not match the required delivery schedule, do not hire more developers. Instead, eliminate some features.

Task Switching

Allow developers to complete the task they are working on before assigning them to another. After coming back to a new task, much time is spent getting familiar with where the task was abandoned and what remaining items are required to complete the it. Along the way, certain technical details can be missed.

Metrics

Gather as many possible metrics you can. Lines of code per method, per class, dependency relationships, and others.

Standards

Ensure everyone is adhering to corporate standards, including:

• Source code formatting. This can be automated, and is not a discussion.
• Naming conventions (variables, database entities, URLs, and such). Use tools when possible, and weekly code reviews to enforce.
• Code must compile without warnings. Note and review all exceptions.
• Consistent (re)use of APIs, both internally and externally developed.

Independent Review

Hire a third-party to perform code reviews.

Competent Programmers

Hire the best programmers you can afford. Let go of the programmers who shirk corporate standards.

Disseminate Information

Hold review sessions where developers can share (with the entire team) their latest changes to the framework(s). Allow them freedom to deprecate old portions of the code in favour of superior methods.

Task Tracking

Have developers log how long (within brackets of 15 minutes) each task has taken them. This is not to be used to measure performance, and must be stressed that it has no relation to review or salary. It is simply a measure of how long it takes certain technical tasks to be implemented. From there you can see, generally, how much time is being spent on different aspects of the system. This will allow you to change focus, if necessary.

Evaluate the Process

If many issues are still finding their way into the software, consider reevaluating the process with which the software is being developed. Metrics will help pinpoint the areas that need to be addressed.

Answer 4

The majority of defects may occur during coding, but the impact of coding defects is generally much lower than the impact of errors made during the process of understanding requirements and while developing a resilient architecture. Thus the use of short executable-producing iterations focused on

• identifying and correcting ambiguous, imprecise, or just plain incorrect requirements
• exposing a suboptimal and/or brittle architecture

can save enormous amounts of time and collective stomach lining in a project of significant scope.

Unit testing, scenario testing, and static analysis tools can detect defects after they are created, but to reduce the number of defects created in the first place, reduce the number of interruptions that developers must endure:

• reduce, eliminate, and/or consolidate meetings
• provide an interrupt-free working environment
• allow developers to correct their defects when they find them (while the responsible code is still fresh in their mind) rather than defer them to a later time when context must be re-established