Build Quality In

The Agile Methods are right!

Abstract

For decades, independent testing has been the accepted "best practice" in quality. Unfortunately, this supposed best practice has not proven to be effective in achieving better quality. Some organizations that have independent testers do well, but many do not. And some organizations that achieve high quality do so without independent testers.

So, what is the common thread? What differentiates those who achieve high quality from those who can't? It is the developers themselves! The old adage is proven true: "You can't test quality into the product; it must be built in."

And it is the Agile methods that have declared this adage to be "best practice".

Agile Quality

The Agile methods are unique in that they don't even mention the concept of independent testers. (They are not incompatible with the concept; they just don't expect or focus on them.) If they don't expect testers, then how do the Agile methods address quality? They include it in the developers' responsibilities.

Developers are expected to not just write code, but to write code that works. The expectation is that when the development team has finished their work, the software is production-ready. This is so central to Agility that "Technical Excellence" is listed as one of the 12 principles of Agility. Continuous attention to technical excellence and good design enhances agility. So, what does it take to build quality in? How do the Agile methods address this principle of technical excellence? They do it through three practices that are found in each of the Agile methods:

Quality Through Collaboration

The first Agile value is "Individuals and Interactions over Processes and Tools". This value contributes to the quality of the software that the developers produce when interaction among the developers becomes a priority.

Individual developers working by themselves do not produce the best systems. The best systems come from teams of developers who collaborate regularly to identify the best ways to build their systems and check each other's work.

Too many organizations view such collaboration as a productivity-busting time waster. Why should two or more people be engaged in work that was assigned to one person? Each person's time (it is thought) would be better spent writing new code than in discussing what can or should be done.

But it turns out that the real time-wasters are the defects and design mistakes that individuals can make when they work alone. eXtreme Programming (XP) values collaboration so highly that it established "Pair Programming" (two developers working together) as a practice to be employed for all technical work! And the other Agile methods encourage collaboration among the developers in other ways.

Quality Through Continuous Testing

The Agile methods expect that every developer is fully testing his or her code both as it is being written and afterward (to guard against regressions). This practice is so firmly a part of Agility that test automation almost becomes a requirement.

Test-Driven Development (TDD) is common in Agile teams. In TDD, the developer writes all of the necessary tests before writing the code. The value of this practice is that it focuses the programmer's attention on what can go wrong and how the program could fail early in development. This results in better designs and more bulletproof code.

And, since the testing is no longer an after-thought, developers tend to give it much more attention and thought than in traditional approaches. This yields both better software and developers who learn to be better testers.

Quality Through Refactoring

The term "Refactoring" refers to re-designing a system that has already been implemented. The Agile methods acknowledge what every programmer knows (that the initial design decisions programmers make are sometimes wrong), and encourages correcting those decisions once the appropriate design becomes apparent.

Developers are reticent to tamper with programs that already work, even when they know it would best be if it was done a different way. And project managers share their reticence. After all, we would rather see new code being written than having something that already works being re-done!

But refactoring is important because it guards against brittle code. Programs are like metal; they can be bent and twisted into forms that were never initially envisioned. But if you bend them too many times, they become brittle. And if a brittle program is twisted just one more time, it will break. We have all dealt with code that was so brittle we were afraid to touch it, because it would inevitably break!

Refactoring is an annealing process code. A metalworker removes brittleness from metal by heating it up and dunking it in water before reworking it. So too, developers need to periodically refactor code so it can be reworked without becoming brittle. Skipping that step (as we often do), causes more problems down the road, and is often the reason why systems must be retired prematurely.

Quality cannot be testing in; it must be built in.

The corollary to this rule is that testers cannot be responsible for quality; developers must be. The Agile methods put the responsibility for quality precisely where it belongs, with the developers. And they do so by recommending a few important practices, collaboration, testing and refactoring.

These practices are not very difficult to grasp, but they can be hard to embrace, because they change our ideas about the role of developers. (But that is another topic for another day!)