Managers need to be able to measure how much can go wrong to assess the size of the programmer's hurdles and get some idea of the man-hours and money required to bring the product to market. Programmers need to be able to measure it, too, to have some yardstick on their own progress.
In much the same way as there is no measure of darkness, there is no measure of quality. You actually measure the lack of these things—the amount of light or the volume of errors. When trying to quantify quality liability you should bear in mind that not all bugs are equal. If you have a colossal program with millions of lines of code and one Class A bug, the entire program is dead. The damage that can be done by releasing it doesn't bear thinking about (as you will discover in the sidebar on the story of the Ariane 5 rocket later in this chapter).
Software measurements polarize around two axes: characteristics and bugs. Characteristics analyze the specification and structure of a program and provide measurements that enable you to compare your program with others. To achieve this it measures such attributes as code length, code complexity, and function. Bugs measure the number and nature of defective parts and the rates at which they grow and dwindle. So characteristics cover both estimated indicators and physically measurable attributes, while bugs measure the dysfunctional results of the coding.
Characteristics such as the number of lines of code do nothing more than alert you to the size of the issue. They mean little in themselves. There is little you can do about them other than rewrite the entire program. You must be aware of them to put other characteristics in perspective. Hitting a sign that says "San Francisco 600 miles" is not much use to you unless you also know which way to go.
Complexity is a much trickier yardstick, though we all know that it means the number of opportunities there are within a program for things to go wrong. Complexity has been analyzed according to structures, algorithms, and cognitions. Characteristics such as these give you insights into how to structure and write programs in simpler, more direct ways so your coding is less prone to errors.
Was this article helpful?