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.
