Software is often seen as different from other products that seem more tangible and less flexible. In this article, Gerold Keefer points out that the perception of flexibility is not always a positive perception, and approaching software as a product that should be "done right the first time" can improve quality. Gerold also illustrates a number of tangible-product metaphors common in the software industry.
"So why is software different? Simple: because we allow it to be different." -Mark Minasi
If you have been involved in software development for some time, you probably heard or said things like, "Yes, but this does not apply to software-software is different." or "We don't need to specify this up front; if it's not what the customer wants, we change it afterwards in the software." The notion that software is different, because it is in constant flux and always easy to change, is quite common in the industry. Although there is no denying that software has properties that distinguish it from the work products of other disciplines, there are advantages in treating software not so differently.
Essentially, software in its good or bad appearances is limited only by our imagination. It is "pure thought stuff": intangible, abstract results of brain activities with little if any connection to the physical world. I'd like to pose two important questions: Do our brains have such little connection to the physical world? Are we completely ignoring the material world as we code software?
If we consider our natural language as a central tool for our thought processes, there are quite a few connections to the physical world. Some twenty years ago, George Lackoff and Mark Johnson published Metaphors We Live By,1 a book that convincingly describes the fact that experiences in the physical world play a major role in our language in the form of embedded metaphors. Even the language we programmers use is full of them:
- We "run" a program, although the only physical movement is that of the hard disk's head while reading or writing binary information.
- Our variable "points" to another buffer, although there is nothing really pointing: The variable simply holds the memory code of the starting byte of the buffer.
- A program is "hanging," although it's not laundry day.
- We are also talking about "higher" quality even though I never measured software quality by altitude.
These are some examples of countless instances of metaphors that help us to understand and communicate program behavior and attributes and make them accessible for our traditional mental models rooted in the world we see, hear, smell, and touch.
If "ease of change" is such a distinct advantage of software, I wonder why even the most agile software development methods do not neglect the necessity for configuration management or at least version management. What else than an artificial barrier to unbounded changes is a configuration management or version control system? Or to give another example: Isn't regression testing a means to prevent changes from causing unforeseen trouble by introducing an invariant called "test suite"?
My observation is that changes are often substantially more difficult with software than initially perceived. If you look at this from the perspective of the CMM/CMMI models, you are more or less at level 2 if you find a way to effectively control change employing the process areas Configuration Management and Requirements Management. In fact, those two process areas are the most often fully satisfied CMM/CMMI process areas, according to the regular industry survey of the Software Engineering Institute. I don't think that's accidental.
Let us turn to another issue: nonvisibility of software. During my studies, when developing software for machine tools part-time, I often got the chance to have a look at how mechanical engineers were debugging their designs. A very clear indication of trouble is metal particles floating around in the oil used for lubrication. A bearing may be worn out or another part may be damaged.
Our software seldom leads to particles of the CPU 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).
References
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.
