The Nature of Quality

How good is your software, really? Is the quality of your product an external factor, imposed by testing and the gradual elimination of bugs, or is it an internal factor originating deep down in the design choices you make and the code you write?

If you already write software of high quality (however you measure it), what is it that you do to maintain that level? Is there a single thing you do, or is the quality the result of a thousand small things all working together?

I contend that Quality is not a characteristic that can be imposed externally. The Quality of a product is not a decision made at any one point - rather, it is a decision made at every point. Quality is an emergent property, the culmination of the thousand minor decisions made every day during the course of the project.

The Real World

Let us turn away for the moment from the virtual world of silicon chips, boolean logic and object oriented design to the physical world.

Large scale engineering projects, like large hydroelectric dams and tall skyscrapers, have an impressive nature that impacts on every visitor. They also have an innate requirement to be of extremely high quality.

Imagine the hue and cry that would erupt if, for example, the Hoover Dam had burst apart as it was filled - or if the first major storm had caused a crack in the main structure and the lake behind the Dam had to be drained before the whole thing collapsed. Alternatively, what would have been the public reaction if the Empire State Building had collapsed under it’s own weight halfway through construction.

No Option

Projects like these don’t have the option of failure - they simply must be constructed to a high standard. How do they avoid failure? They obviously don’t use the approach typical of much of the software industry - build the whole thing and we’ll fix the things that don’t work after we release it to testing.

Instead, these project build quality in from the very start. They plan exactly how good ( heavy, strong, flexible, expensive) the dam or skyscraper will be, well before the first construction vehicle arrives on site. Any changes made to the plans of the building, say to better reflect the nature of ground underlying the structure, are made with a view to maintaining the appropriate level of quality.

The designers of heavy vehicles such as trucks, buses and heavy diggers do the same, specifying as a part of the original design the hardness and strength of steel required for each bolt that holds the machine together. Specify too strong a bolt and the vehicle becomes too expensive to build; too weak and the vehicle’s structure fails at exactly the wrong moment, with potentially fatal consequences.

Real Testing

Does this constant attention to quality mean that formal testing is discarded? By no means - there are always the possibilities of human error and unexpected circumstance.

For example, Hydroelectric projects always include a test fill of the new lake, during which the structure is carefully monitored for stress and how it handles the weight of the water. Engineers working on tall buildings constantly monitor the way the structure is reacting to the increasing load, ensuring that any problems are discovered well before something collapses.

Similarly, severe stress is placed upon prototype vehicles (often to their destruction) in order to verify the correct level of strength and durability (and therefore safety) has be achieved.

The goal of the testing isn’t to build in the Quality at the last moment - clearly that is impossible with projects of this scale.

In fact, the required level quality should already have been attained as the culmination of all the day to day decisions made during the construction. No matter whether a skyscraper or a hydroelectric dam has been built, every decision made en route - from the grade of concrete used to the choice of tint on the windows - contributes to the overall effect.

The goal of end-of-project testing isn’t to catch any errors and fix them - those errors have been caught and fixed long before. The goal is to verify that the planned level of quality has, in fact, been achieved.

Software Testing

Such a role, of quality verification, is the role that formal system testing should play in the software industry - as a formal, systematic and rigorous verification that the system works ( and fails) in the way designed.

All too often, however, the testing team becomes the primary source of bug reports for the development team to fix, rather than the source of verification that the quality of the systems is sufficient.

What is it that so commonly goes wrong? Why does the Testing team often end up enforcing a level of quality instead of simply checking that it has been reached?

In many cases, it is because the requisite quality is not built into the system at the beginning and it’s lack isn’t discovered until near the end of the project.

The causes of poor quality are many and varied, ranging from sloppy code and poor design, to miscommunication between team members, overbearing schedule pressure and a simple lack of attention to details. Whatever the cause, however, the result is the same - a brittle system that mostly works, most of the time. The dangerous nature of these systems is that while they always seem to be just a hair from working correctly, every fix seems to reveal more problems around the next corner.

The Swiss Lesson

The most impressive engineering, the projects that garner respect from within the relevant industry as well as without, are usually those that are consistently elegant and well constructed throughout.

Consider the finest Swiss watch - it’s exterior finely crafted and superbly build, with pieces that fit together so snuggly that you can barely see the joins.

If you dismantled such a watch (carefully, please) you’ll find the same attention to detail and quality throughout the interior as was applied to the exterior. Every piece is exquisitely made and finely balanced with nary a blemish or even a spec of dust to be seen. This is true even though the craftspeople who created it expected that very few others would ever see inside.

The high quality of the watch as a whole derives entirely from the high quality of the pieces used to make it, and from the way they interact in exactly the way intended by the original watchmaker.

Quality is built in

The Quality of software derives from it’s components in exactly the same way as the quality of the watch - it is built in from the smallest function to the largest object.

In order to build high quality software - software that does what it is supposed to do, systems that are useful, usable and reliable - we need to ensure that the pieces we use to build our software are themselves of high quality. Moreover, we need to take the time to understand those pieces so we can use them correctly, and to integrate the pieces together correctly.

How high is the quality of your Software? How good are it’s pieces?