Let’s kill all the metaphors. You know which ones I’m talking about.
I was reading through Neal Ford’s comments on "Building Bridges without Engineering" and started to groan. I enjoy reading Neal’s blog, and his comments are generally insightful but this rekindled a conversation I had a few days ago on this very topic. And it seems I keep having this conversation all too often, but from now on, I’m done with it. As for why, refer to an earlier post by Neal from several years back which I quote below (emphasis mine):
It seems like every time someone talks about the job/craft/calling of writing software, they tend to end up with a bunch of tortured metaphors (engineering, woodworking, rock climbing, gardening, etc.).
None of these analogies hold up past just superficial scrutiny. I think
that it’s a reflection on how different it ultimately is.
I completely agree with Neal here, but he doesn’t go far enough in calling us out. As practitioners, we often groan about the use of such metaphors, but even those who try to negate them still hold on to the belief that, given enough time, the discipline of software development will eventually mature to fit those metaphors. For something such as software which is more pervasive than bridges, more influential to our daily lives than the automobile, it really says something about the immaturity not of our discipline, but of the software development community that we feel the need to reach for these types of metaphors at all. Even in dismissing or diminishing the usefulness of the metaphor, Neal, like many others, ends up going right back to the well in his more recent post:
We’re currently at the level in software where bridges builders [sic] were when they built a bridge, ran a heavy cart across it, and it collapsed. "Well, that wasn’t a very good bridge. Let’s try again".
Whereas before I used to strive to explain software in terms of other engineering disciplines (if for no other reason than to show how they differ) I don’t do this anymore. I don’t hold to the teleological belief that, 50-100 years from now, we will finally figure
out how the process of developing software somehow conforms to
other, more established engineering disciplines. There is no "figuring out" to do. A more likely scenario for the future (as sobering as it may be)
is that generations of individuals who were not born into a life
where software concepts were so pervasive (myself included) will senesce and eventually pass on, and the original need for these metaphor will become irrelevant for future generations. For all we know, other areas of engineering may just as likely start using software engineering as their metaphor, and argue amongst themselves over why ‘X’ is not like ‘Y’ where ‘X’ is some aspect of study, and ‘Y’ represents software concepts like iterative development, TDD, the First Law of Distributed Objects, YAGNI, etc. Strange to think that such a "nascent" discipline as ours could be used to guide people across the next divide, but it could happen.
Metaphors exist for a reason- to bridge the gap between two seemingly disparate realms of thought. As such, they are still useful and I employ them quite a bit when when mapping software solutions to a non-software problem. But the process by which software itself is developed does not lend itself to any metaphor that I’ve ever seen put to use. I’ve come to find that using other engineering disciplines as approximations is a stale idea. To try and mold the software process to another form will almost always end in tears for the customer who needs it explained to him in such ways, and is a disservice to those who will ultimately follow in our footsteps. As far as metaphors go, they probably won’t need it anyway (i.e. ‘TAGNI’).
