The term "war on terror" has always made me squirm. But there's no denying the power of the metaphor. As a recent article in Scientific American argues, the metaphor you choose defines the way you think. Call the incompatibility between the West and fundamental Islam a "war on terror" and you are forced to think about how best to beat the "enemy" into submission; how to crush them militarily. It becomes a zero sum game, to be settled with violence.
But what would happen if you changed the metaphor? If you were to choose the metaphor of terrorism as disease, or crime, rather than military enemy? Then you would think about the problem in different ways. Rather than war, you might consider innoculation or policing as effective counter-strategies.
But this blog isn't about politics, it's about software. The reason I bring up the "war on terror" is because of something Tim Lister said last week. I'd always thought about our product plans as a "pipeline". But Tim said that his preferred metaphor was a bookshelf*.
Define product plans as a pipeline, and you immediately start thinking about funnels, filtering and distillation. You think about linear progression, of ideas entering the pipeline at one end and then emerging, linearly, first in first out, from the other. You worry about filling the pipeline and keeping the ideas flowing.
But change the metaphor to a bookshelf, and everything changes. Filling the bookshelf becomes a parallel task. You can put up different types and sizes of books, and you can take them down in any order. You pay attention to the book covers – how to make the book look good, and what blurb to put on the dust jacket so people will choose to pull your book off the shelf and read it.
What would happen if we changed an even more fundamental metaphor?
We aways talk about software projects. The word project makes you think of planning, spreadsheets, milestones, checkpoints and gantt charts. What if we chose a word other than project? What if we called them software organisms, or software shrubs, software herds or software jigsaws?
Would that change the way we thought about writing software? Would we come up with better ways of shipping software?
And how about "shipping" software? Is that another metaphor ripe for challenge?
Post your comments here …
Enjoyed this post? Follow me on twitter, or subscribe to my blog's RSS feed.
[* The bookshelf metaphor was actually one that Dom made and Tim picked up on]
First of all, a word on “war on terror”. Yes, it’s probably a very aggressive metaphor (no positive “vibe” jumps out of it), but behind this current incarnation of the metaphor is a long string of escalations. First it was combating, then it was deterring, then it was fighting – and none of those were effective. The more and more brazen acts required a more “definitive” stance, hence the escalation to a war-based metaphor. It simply signals determination (and exasperation) – nothing else. One last point on this topic: terrorism does not stem from the incompatibility between West and fundamental Islam. That incompatibility is a safe harbor for terrorism, an improbable but serviceable attempt at justifying the acts. For more on this, please read Bruce Schneier’s piece in Wired (search for “terrorists”, it’s a recent article).
Now then – on to changing the metaphor on software. Sorry, but no, thanks. Metaphors are all about press and public perception. The internals, the workflows do not, cannot, should not change because the buzz word of the day changed. You can’t change the way you produce software anymore than you can change the way you produce a car.
Take your example, the bookshelf metaphor. I admit I’m not entirely sure what was meant by it, whether the bookshelf is your internal organization, or it is the entire market, and the other books are competing products. If it’s the latter, then the new metaphor is orthogonal – it’s simply what happens at the end of the pipeline-based view. It is the user’s view, rather than that of the producer. If it’s the former, then it’s even less useful, as it seems to promote anarchy, or at least “fuzzier” planning. (I’ve never written a book, but we can probably agree that book writing is also a pipeline-like activity. At least good ones.)
Brushing metaphors aside as simple labels, the right approach (to me, at least) is to identify the ills of the current “view” and go about fixing those, rather than change the “view” altogether. If the problem is rigidity of schedules, or scope of releases, or the palette of products – then no view change will fix these – they are hard problems and must be dealt with (sometimes on an individual basis, unfortunately).
Shipping software – I’m personally fond of it. There is something definitive/irreversible about it that expresses perfectly the hard decisions one must make in releasing software.
DA,
Thanks for the really detailed reply.
You say that “you can’t change the way you produce software any more than you can change the way you produce a car”.
I’d argue that you *can* change the way you produce software. And cars too. For example, by calling software as a “service” (as in SaaS) changes the metaphor and, I would argue, the way you think about things.
The way that cars are produced has changed a lot over the past decade – not justincremental changes, but fundamental changes of philosophy (eg from Fordism to, say, the Toyota Way). And it could – and should – change more. See, for example:
http://sethgodin.typepad.com/seths_blog/2008/11/what-to-do-abou.html
I’d argue that the metaphor doesn’t have to follow the reality. If you came up with a metaphor other than “big car company” or “car factory” that might create new, useful ways to think about the problem.
My pipeline / bookshelf was meant to be about how you come up with ideas, how you qualify them and how you move from a stream of poorly thought out ideas into concrete proposals for a small number of software products. You’re right though – my description wasn’t clear.
Anyway, thanks again for the reply. I appreciate the time you took to post, even if I think we disagree.
– Neil
Neil,
thanks for your reply. Though my post was “detailed”, I went very quickly over the car production analogy, so allow me to explain.
Yes, the details of car production changed tremendously but the changes were improvements/optimizations. The Toyota way, for instance (which, in fact, was an evolution of the Ford system) gave us JIT – it doesn’t change the paradigm, but optimizes “lock” times by parallelizing the production and thus eliminates the need for buffers. But it’s still pipeline.
To produce anything, one still needs a set of requirements, a plan, a design, a strategy and serialized/staged delivery. How various stages are implemented is (IMO) a detail that is subordinated to the pipeline model, rather than diverging from it.
I hope this clarifies my post, even though it may not be enough to bring us to agreement. 🙂
Cheers,
Dragos
Metaphors are all about perception. They highlight a way to think about a process or problem. Testing out new metaphors is a way to look at your current processes and discover new approaches and possibly, new innovations.
If the processes we use cannot and should not be changed, we would still be programming a computer with punch cards or flipping switches on a panel.
To innovate, we have to look beyond our current perceptions and looking at different metaphors for what we do is one way to do that.
Steven said: “If the processes we use cannot and should not be changed, we would still be programming a computer with punch cards or flipping switches on a panel.”
Yes, and in a few years, you won’t type, but you’l dictate to your computer in natural language, and the corresponding code will be generated.
That still doesn’t change the way projects are managed.
Don’t get me wrong, I do see your (collective) points; I’m just not sure we (as an industry) have already exhausted all the opportunities for optimizing the current “metaphor”.
And besides, I think the metaphor follows the solution, not the other way around.
Cheers,
Dragos
We need to change more metaphors than just developing software. How about the soul-sucking words of business like using “resource” instead of “person?”
My suggestion for a new metaphor: Software cultivation.
Metaphors do matter. But they aren’t enough. Simply changing the label doesn’t make change. However, a change to the label in the context of changes to processes (prescribed behaviors) and results can be powerful.
Teams that start using Agile methods and perform a Sprint or Iteration behave differently. Yes, this is because of the “rules”. (Aha, the label is different, it is not called “process”!) But the attitude becomes different because it is not “this month’s project” it is “this month’s sprint”.
If you stop “fixing bugs” and instead “remove defects” (with some associated behavior changes), you will find that this can also create a dramatic change.
A new metaphor is a nice starting point, but [warning: metaphor coming] it is only a stand upon which you can build a new framework.
So while software-as-a-bookshelf sounds like an interesting thought experiment, it will only be an effective metaphor when we understand how to practically apply it to our short and long term thinking. (I also like Jason’s “software cultivation”. Do I have to wait until after last frost to plant?)
> Metaphors do matter. But they aren’t enough.
> Simply changing the label doesn’t make change.
Yes, changing the label is not enough. But changing the metaphor is enough (in theory, at least; see Lakoff & Johnson).
Metaphors describe the way one thinks and feels about things. It