Not sure where I first heard the phrase “you can’t inspect quality into a product” but I have certainly used the phrase myself all too often in my consulting gigs. After a quick Google search, I found the originator of the quote was Harold Dodge and it was first used in a manufacturing context. While I generally eschew appropriating manufacturing analogies for comparison to software development, in this case, it is certainly apt.
In many of the companies I consult with, the prevalent view of “quality” is nothing more than inspection after the fact, a misplaced notion that quality can be insured by finding all of the defects built into the software. The great majority of these inspections are conducted by a separate team, a half a world away by manually banging on keyboards and mice. If one were to write an article on how NOT to ensure software quality it would look frighteningly similar to this (which is what I experience all too frequently when I work with companies).
I find that often this goes hand in hand with the mistaken notion that we are performing projects as opposed to creating long term stable quality products. In some cases our quality leaders are merely naive or simply unquestioningly following the misguided policies and practices of those who came before. For those who truly wish to understand true software quality, who desire to build quality into a product instead of merely trying to inspect it out, what practices should we use?
The first thing is to recognize that building quality into our software code must begin with those who are building the software, the developers. We might have some nice motivational posters that state quality is everyone’s business, but until we tear down the arbitrary and dangerous walls we have erected (incorrectly taking waterfall to its bizarre conclusion) between development and “testers” we will certainly fail to put quality into the code. Development can ensure the quality comes first by writing tests first and performing true TDD (test driven development).
Sometimes, as Dan North found, developers may be convinced that TDD is a great idea yet find it difficult to implement. This is a great opportunity to inject BDD (behavior driven development) as a means of helping developers with TDD. In fact, I often recommend that BDD style scenarios can be used to express acceptance criteria even if developers are not yet ready for TDD. The tremendous increase in understanding and early inclusion of test cases as expressed through scenarios is the biggest benefit of BDD and goes a long way to injecting quality into our code.
Another technique for injecting quality is the concept of code review. There is nothing like another set of eyes to make sure that our code is high quality before we push it out of the development environment. You may want to go one better and get a more immediate feedback through pair programming. Like many things in software development pair programming is counter intuitive but the quality of code produced by judicious use of pairing far outweighs the perceived “double” expense.
Akin to code reviews conducted by humans is the ability of code to be “reviewed” by software through static code analysis tools. This software can “read” code and determine “quality” through a set of programmed rules. It will, for example, let you know which classes are too long or complex. These rules become instant feedback for code in progress and help us to easily avoid technical debt. For existing code these tools can help us to understand existing code quality and provide us with candidates for refactoring.
Whatever the technique you choose, the key is to understand that quality is something that is built into the code not something that we can inspect out.
