The smell of software

Recently I’ve been working with my team of XML Summer School lecturers on our materials, and Jeff floated the idea of a using a visual metaphor to show how each topic fills in another piece of the web services/SOA story. Paul advised against using “puzzle pieces”, which imply that the picture isn’t complete until you use every last piece. So we brainstormed some alternatives. (My unserious suggestions: onions and bricks…)

A common metaphor is Lego(R) and Duplo(R) pieces, which, due to a single standard (in this case imposed by the Lego company itself) for fit, always go together. But we can see that different “stacks” might not:

Lego-like conference swag

(It’s hard to see, but the upper one comes from DataChannel.) I found these while cleaning out my home office desk a few weeks ago, and immediately noted that they were not interoperable…

While hunting for additional useful metaphors, I googled “layering metaphors” and came across this fascinating paper on Software Metaphors. From the introduction, titled “Software as Fiction”:

As fiction, software is entirely and thoroughly metaphorical. Metaphors pervade every element and aspect of software, from the lowliest variable name to the largest of enterprise architectures. Software is so steeped in metaphors that we often overlook the extent and nature of these metaphors. Like fish in water, software developers often do not perceive the medium that surrounds us: our natural languages, natural conceptual models, and the natural and linguistic metaphors we use every day in our software designs. Even so, software developers borrow ideas, terminology and organizational structures from every field they encounter and every problem they solve.

Indeed, our brains can’t help applying patterns — and the most concrete and atom-based patterns, like the “Bad is Stinky” and “Categories are Containers” examples given in the paper, are the easiest to make because we’ve been familiar with those referents for a whole lifetime. In fact, every time we use a preposition, we’re making an implicit physical-relationship metaphor (this module hands control to that module; the UI goes in front of the business logic).

The paper is chock-full of interesting thoughts and even advice on effective naming of things like variables, taking into account their metaphorical roles. Its stated goal — “This essay explores a wide variety of these metaphors in hopes of awakening a greater awareness of them in software developers and in hopes of making their acknowledgement more common and explicit in the general practice of software development” — is pretty modest, but its encyclopedic collection of metaphors used in the creation and maintenance of software is impressive and fun to read. (The attempt to catalog every metaphor puts me in mind of Douglas Hofstadter’s Fluid Concepts and Creative Analogies, which describes his team’s attempts to duplicate in software the sorts of nano-analogy-making that minds do all the time — sort of a reverse view of this paper.)

Imagine my delight when I found the section connecting code threads to stitch patterns (for which this is a reverse view!):

Computer processors are now generally fast enough that they can usually switch between and effectively trace several execution threads “concurrently” according to human perception. Thus, execution threads can be likened to the straight warp on a loom, around which intricate patterns of code are entwined and intertwined to produce a fabric of data as results.

And there’s a section called “Mathematical Formulas, Impurities and Stench”, which explores the “bad is stinky” realm — for example, discussing a book on software refactoring that refers to “(deodorant) comments” used “to mask bad smells in the code”.

With apologies to William Steig and Ted Elliott (and thanks to Robin), perhaps software really is most like onions. (They stink?) Yes — no! (They make you cry?) No! (You leave them in the sun, they get all brown, start sproutin’ little white hairs?) No! Layers! Onions have layers. Software has layers! Onions have layers. You get it? They both have layers.

The logic seems irrefutable.