being distributed around. Well, I said seldom-not never. However, by the means of logs and tracefiles we are similarly trying to "see" the effects of our software. We are artificially producing scratches and abrasions that guide our course of action to improve transparency, and with it, quality. Another aspect is visualization. I analyzed software with a call graph and immediately noticed that four functions were never called. Quite impressive code visualizations were developed by Thomas Ball and Stephen G. Eick on program changes, static properties of code, and run-time behaviour. 2
At a higher level, I consider the presentation and accessibility of measured data to be most crucial for the success in the application of software metrics. Very often, successful larger software-development organizations rely heavily on transparency and visibility of their work products, processes, and metrics data, bringing it to a level where you can "see" the quality. In this sense the journey from CMM(I) level 1 to level 5 should probably be interpreted as a journey from obscurity to transparency and from disguise to visibility.
Although software is a world of its own, making it tangible and visible is possible, advantageous, and improves quality. And treating software development like more "tangible" products-as though you have to get it right the first time-might just improve quality throughout the industry (and improve your business).
1 G. Lakoff , M. Johnson, 1980, Metaphors We Live By, University of Chicago Press (Trd).
2 T. Ball, S. G. Eick, Software Visualization in the Large , IEEE Computer, Vol. 29, No.4, April 1996. pp. 33-43.