No bugs! Sounds good! Is it feasible?
Can agile software developers create software with no bugs? Image if they could. Think of all the time that would be saved testing, re-testing and testing some more. All that time spent repairing things that weren’t done correctly becomes time to spend on making the software better and faster.
It is a feasible goal.
Achieving it means thinking about the process of writing software differently. Some agile teams are proponents of pair programming believing in the theory that two heads are better than one. Pair programming can help but it alone won’t get you to zero defects.
To go all the way, consider adopting all of the following techniques:
- Pair programming or at a minimum peer review. Some form of community participation will always result in better code than can be produced by an isolated developer.
- Test-driven development. You’ve heard it before — write the tests before the code. You need to go one step further though. Someone other than the person writing the code should write the tests. Don’t isolate them. Have them collaborate and develop a common understanding of what the code must do.
- Define coding standards and enforce them. We all take shortcuts when we’re rushed (and we are always in a rush). Coding standards will help ensure that the code is written properly.
- Get your customer actively involved. Misunderstandings around requirements, stories and features are common. The only way to prevent them from becoming defects is to engage the customer.
- Allocate time to pay down technical debt. Debt is inevitable. Defects are not. The more debt you build up, the greater the likelihood that bugs will infest the code.
- Track the source of defects that make it through. Look for patterns or common sources of mistakes. When you identify them, take steps to prevent future occurrences.
- Lastly, automate your regression testing. A simpler and faster testing cycle will result in more testing which will uncover more bugs before the software leaves the development team. This is a last resort and the number of bugs found at this stage should be minimal.
The most important goal is to prevent bugs from reaching the customer. It won’t be easy, particularly if you are dealing with a large base of legacy code, but it can be done. Care to comment?