What’s in a Word? From Science to Software

In my previous post (Are We Abusing Science?) I wrote that we need to be careful when applying terminology from the sciences to software development. When we don't fully understand scientific terms, while attempting to use them in another domain, we run the risk of being scolded and ridiculed by scientists for our abuse of their cherished terminologies. And we don't want to be shot at with the Large Hadron Collider, now do we?

There are three ways of "borrowing" terms from other disciplines:

Metaphors
We use metaphors to make people understand concepts more easily, without having to make sure that descriptions are accurate and consistent in meaning. For example: in chaos theory the butterfly effect is a metaphor for the unpredictable consequences of small changes. It is a fine example of a metaphor in science. (In fact, in order to get their work funded, scientists often resort to metaphors to make their work somewhat less incomprehensible.)

There are so many metaphors being used in software development that it is hard not to think of any. Bugs, smoke testing, spikes, waterfalls, factories, server farms, black box testing, binary trees, software crashes… Shall I stop already? Such metaphors are very useful for furthering the understanding of complex ideas. But there's a problem with them as well: they always fail at some point when taken too far, and this could result in the metaphors leading someone down false paths.

Strict Terminology
A different way of copying terms from one discipline to another, is to make sure that their meaning is strictly identical in all cases. For example: non-linearity means exactly the same in all sciences, whether it is physics, mathematics, economics, or anything else. (Though whether economics really is a science is still open for debate as far as I'm concerned.)

Perhaps the best example in software development is the word system. Though the word has its origins outside of computer science, the meaning is the same in all disciplines: a set of interacting or interdependent entities forming an integrated whole.

Strict use of terminology is the preferred approach of dogmatic scientists. And I would say that they tend to defend that position religiously, but that would be like practicing suicide with my own words.

Loose Terminology
Sometimes neither metaphors nor strict terminology are helpful. A third approach to applying terms from one discipline to another is to do this more loosely than the strict approach requires. In such a case a term will still carry more or less the same meaning, but it will be adapted, extended, or narrowed down, to better fit the new domain. For example: business management has copied the term culture from anthropology. What a business culture means for a business is pretty much the same as what a social culture means for a society. But there are some important domain-specific differences. Likewise, the word strategy in business strategy has been borrowed (and then adapted) from the military.

Even more interesting: the science of game theory has borrowed the term strategy for evolutionarily stable strategies. Here it appears that scientists too know how to borrow and bend terminology to their advantage. And I'm not one to blame them.

For our own domain, a fine and familiar example would be the word architecture: software architecture, systems architecture, information architecture, and several other kinds of architectures, all have their own specific meanings, slightly adapted from the original word which deals with the design of buildings.

And That's How We Do It
The loose application of terminology, through the borrowing and bending of words from other disciplines, enables us to inherit meaning from elsewhere, while remaining flexible enough to modify that meaning to match our own domain.

It also requires scientists to be flexible enough not to accuse us of abuse of science. But, considering that scientists so often apply metaphors and loose terminology themselves to make their work understandable, I am quite sure we will be able to get away with it.

(image by powerbooktrance)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Self-Organization = Anarchy (Part 1)
Simple vs. Complicated vs. Complex vs. Chaotic
From Complexity Theory to Practical Management

Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://javadots.blogspot.com/2009/08/why-aircraft-carriers-are-not-agile.html Itay Maman

    The danger with reusing terminology (of all kinds) is that it serves as a black box that carries some fixed meaning. This promotes discussion and reasoning as you don’t need to redefine the same concepts from the grounds up. Instead, you use a widely acknowledged which encapsulates all the tiny details. This is certainly a positive thing.
    However, this is exactly where the problem lies. When you reuse terminology, especially from a different discipline, chances are that some details inside that black box will not be true in the new context. People rarely devote time to verify that every tiny detail encapsulated behind the term is correct in the new discipline. This often leads to false premises and therefore to false conclusions.
    A concrete example will be the architecture terminology. Some aspect of software development are similar to construction of building. Other aspects are not. However, once the “architecture” terminology gain momentum people started using it indiscriminately, thereby misusing it. From this point onward, it is a very risky path:
    If a software is like a building it is only natural that you can also have blue-prints for a program and that these blue-prints will be just as accurate as in building construction. Complete methodologies (Waterfall, RUP) were built on top of this line of thinking which originated from transfer of terminology. Sadly, blue-prints in software can never be accurate. They can deliver the same level of precision as in buildings. This is not an issue of maturity – this is the inherent (harsh) reality of computer science: http://javadots.blogspot.com/2009/08/why-aircraft-carriers-are-not-agile.html

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Thanks, these are great points!

  • http://www.softechms.com/ Office Switches

    The study of computers, including both hardware and software design. Computer science is composed of many broad disciplines, including artificial intelligence and software engineering

How to Change the World - free Workout - free
CLOSE