Names

In the wrap-up session of a week-long course in program design, one participant made a trenchant comment. "Before I came to this course, I think I already had some of the concepts we have talked about here," she said, "but now they have names, and that makes all the difference."

She was right—it does make all the difference. A name is the ultimate abstraction: it conveys a cluster of ideas, experiences, or anything else, in the smallest possible compass. In strictly formal discourse the meanings of names for concepts can be perfectly precise: a formal name acts as a shorthand reference to its formal definition. In everyday use, and more generally, the value of a name does not depend on such precise semantics. On the contrary, uncertainty at the fringes of a name's meaning can lead to fruitful exploration of the boundaries—especially when the name is making its way from conception to a wide general acceptance.

In a development discipline the establishment and common use of a vocabulary of names marks its evolution from radical towards normal design. In a well-known investigation [1] of failures of a radiotherapy system, discussion of the physical hardware and its functions could refer to normal components by name—X-ray Mode Target, Flattener, Scan Magnet, Turntable, and many others. Discussion of the software, by contrast, was hampered by the absence of normal design, clearly evidenced in the lack of established component names. The only available references were to the names of program subroutines—both names and subroutines being unique to the particular software, and invented and assembled ad hoc.

A notable success in the evolution of software development has been the use of object-oriented patterns. The Model, View, Controller pattern was introduced in 1979 in Smalltalk and subsequently developed into several different versions. In their 1994 book [2] the Gang of Four presented and discussed 23 distinct design patterns. Critically, each one is given a carefully chosen suggestive name—Chain of Responsibility, Abstract Factory, Mediator and twenty others. In their concluding chapter the authors write: "Cataloguing design patterns is important. It is important to have standard names and definitions for the things we do. If we don't study the patterns we use, we won't be able to improve them, and it'll be harder to come up with new ones." Yes, indeed.

Naming is a difficult matter, and not only for cats. As T S Eliot [3] recognised, a name is not a meaningless identifier. A word chosen from the vocabulary of a natural language, or the linguistic flavour of a new coinage, carries connotations influencing its understood meanings in a changing context. The advance of software engineering has been severely hampered by two particularly unfortunate names—system and environment. For too many people the name system still denotes the computing equipment alone—what we are calling the machine—just as it did when the computer's primary role was calculating numbers and manipulating texts. In the same way, what we call the governed and requirement world is too often called the environment—a name that clearly suggests an indifferent surrounding ambiance that may, or may not, tolerate or obstruct the purposes of the system. Squeezed between these two naming solecisms, the bipartite system vanishes from view. Names matter a lot.

[1] Nancy G Leveson and Clark S Turner; An Investigation of the Therac-25 Accidents; IEEE Computer 26,7 July 1993.
[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides; Design Patterns: Elements of Object-Oriented Software; Addison-Wesley, 1994.
[3] T S Eliot; Old Possum's Book of Practical Cats; Faber and Faber, 1939.

 → Cyber-Physical Systems: The essential character of a cyber-physical system
 → Radical and Normal Design: From cradle to adulthood of an engineering product