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