Wednesday, March 26, 2008

Need for a new Metaphor

Software Engineering suffers from many things, such as bad management; however, I want to focus on an aspect that I feel stands at the heart of things.

A Bad Metaphor

Somewhere in antiquity, before 1990, people got together to categorize software engineering. Some described it as an art while others wanted it to be a science, or an engineering discipline similar to civil and mechanical engineering. The science advocates won...mostly. I say this because the nomenclature, journals, writing, etc. points towards SE being a science, where practice shows it is sorely lacking in this regard. SE is an art.

Back to our bad metaphor

In describing SE as a science, SE Management became identified with Construction Management. You can see this in names: Architect, Project Manager, Subcontractor, etc. You can see it in the way construction projects are built: requirements gathering, design, blueprints, foundation, framing, roofing, drywall, inspection, sign-off, etc. It is eerily close to the Waterfall method, which most will contend is the worst way to build software of any significance. Obviously, the software as construction metaphor is just plain wrong. Unfortunately, there are similarities and that is where people get sucked into thinking it is correct, or at least "good enough."

Another bad metaphor

Currently, there is a trend to identify SE, or at least hacking, with painting. This is seductive but ultimately laughable. I firmly believe that SE is an artistic effort. This is why great developers are 10x to 30x better than average developers; however, the similarity between SE and painting is superficial. I say this because, while both are arts, painting has not offered any useful insight into creating better software.

We could try to correlate painting layers to an n-tier design or how you really have to think about your art before you create it, but these examples seem contrived and more importantly offer little real value. What we need is...

A new metaphor

So far I have come across two metaphors that I think are much better than the current crop; however, I am currently at a loss as to which is the more accurate.

SE as poetry

The first metaphor comes from Alistair Cockburn. At least that is who I learned it from. He stated, "What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together (Cockburn, Agile Software Development, v2, p29)." He goes on to describe how the the communal effort would take place, where there would be key poem designers, lead poets, not-so-good poets and great ones, non-poets who are involved in quality and sales, etc. You get the picture. Mr. Cockburn's solution to this scenario is proper communication.

SE as gardening

I first started thinking about this metaphor in mid 2007. Think of a garden. You have all types of plants: flowers, annuals, perrenials, grass, trees, bushes, etc. You even have non-plant items: sidewalks, benches, bird-feeders, etc. All of it has to work together for an overall effect that the owner, or designer, wanted. In addition, it has been built over time by different people with different specific goals.

This metaphor has lots of correlations:
The owner may have switched designers. The suppliers ran out of one type of tree, so they used another similar type. New designers and workers came in months after the old team left. A tree can represent a giant monolithic program, where grass is a distrubuted program. You can even discuss viruses, fungi, and literal bugs that negatively affect your garden paradise.

It is because of this that I feel that the best current metaphor for SE is Gardening.


kalid said...

Hi Dan, interesting post! I've had similar issues trying to describe software engineering.

I think one giant difference between software engineering & other disciplines, such as Construction Management, is the idea of "structural stability" (I'm not sure of the right word).

With most buildings, if you misplace a brick or make a wall a bit thin, the building still works. In most cases these defects aren't a big deal (houses get cracks, floors creak), and occasionally problems will surface under stress (hurricane or flood exposes structural weaknesses & the building collapses; but wouldn't it have anyway?).

Software is different from most engineering disciplines because a program can go from "working" to "not working" with a single typo or "off by one" error. Logic errors generally have the ability to crash or corrupt the entire program. These can be detected & isolated with asserts like the compartments in a ship, but the potential is always there.

In that vein, software may be like poetry, literature or even a legal contract. A "typo" can completely reverse the meaning of the program, whereas you can't really have a "negative window" in a building.

I'm still not sure what metaphor fits best, but I think one related to writing may be on the right track. Gardening is interesting because it seems like a combination of science/engineering & having a "feel" for the plants (a green thumb), knowing when to water, change pots, rotate crops, what to plant where, etc.

Dan said...

Great point about poetry and software going from "working" to "not working" with a single typo. I think another field with that issue is song-writing. One note can change a piece from incredible to something else.