Steve McConnell observed as early as 1993 that, “trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often.” This quote from Code Complete is as true today as it was then.

I joke with my team that “testing” to improve product quality is like trying to make your car go faster by looking at your speedometer.

Why then, am I the CEO of a company that chooses “Test Early” as its motto?

Because testing – specifically, developer testing – is the most powerful way to assess the quality of code and introduce meaningful practices to improve code quality.

There remains an ongoing debate about the economic impact of software defects, the relevance of testing to address that economic impact and even the definition of “quality software”.

But, without testing – again, early developer testing – software developer teams are flying blind and relying on the implicit hunches of their most influential members.

Note that I used the phrase “most influential” rather than “best programmers.” Anecdotal evidence should assure the majority of us that these two groups are often not the same people.

My company focuses on quality of software during the manufacturing process. An analogous example would be to say if we were in the automobile industry, we would not examine a completed automobile, nor would we examine the plans for an automobile. We instead inspect and improve every step along the assembly line.

It is clearly true that a car with poor design plans will likely have poor quality – even if every step along the manufacturing process is executed perfectly. Also, a well-designed and built car could have little financial success if the final, completed product does not resonate emotionally with the car-buying public.

So, gaps in design and market assessment can have material impact on the quality of applications, independent from the effectiveness of the manufacturing process.

I believe, though, that the software industry’s biggest gap in competency actually lies in the manufacturing process itself.

Ask any VP of Engineering or Director of Software Development to provide metrics for the overall cyclomatic complexity of an application. Or the ratio of unit tests to complexity. Or the rank of modules by their dependency from other modules. Or the frequency and coverage of executing unit tests. Or the frequency and duration of a complete build of an application for final production.

My experience is that very few engineering teams give meaningful service to these critical measures of the software manufacturing process.

Does that mean that the code quality of these teams is poor? No. It just means that an assessment of code quality is based on the input of the most influential members of the team rather than independent, objective measures.

Another joke of mine is, “I’m not only the hair club president, I am also a client.”

I embraced this idea of improving software manufacturing by contracting a consulting firm a few years ago for my JNetDirect product business. I was so impressed with the way early software quality can transform the way developers engage in the creation of code that we acquired the company and launched Stelligent.

While testing does not make software better, it does give objective feedback regarding the quality of code that constitutes the product. Constructing meaningful tests that (1) become an artifact of the code repository and (2) are executed with every change to the product will provide real feedback to the engineers who author code.

Looking at your speedometer will not tell you why the car is moving slowly, but it might remind you that you have left the parking brake engaged before you start smelling the fumes from your brake pads.

As in any competitive endeavor, you cannot win unless you keep score. If improving software quality is your goal, you need the scoring mechanism of developer testing to gauge the effectiveness of your efforts.

Testing may not make better software, but it will let you know whether the software you are making is getting better or worse.

Without testing, you are playing the game with your eyes closed. You might score. Then again, you might be shooting at the wrong goal.