Powerful metaphors for software development
A metaphor is an analogy between ideas. We use metaphors to explain or understand something in terms of something else. Some metaphors are implied by everyday phrases, e.g. “the foot of the mountain”, “raining cats and dogs” and “time runs fast”. The latter one is particularly interesting. Time is a concept that can be hard to grasp, at least compared to mountains and rain. The expression “time runs fast” implies that we think of time as physical movement or a journey. This will make us think of not only time but our lives as a journey.
The tendency for us to think in terms of metaphors is so widespread that Jonathan Haidt, a professor of psychology at the University of Virginia, claims in The Happiness Hypothesis: Finding Modern Truth in Ancient Wisdom that humans need metaphors:
Human thinking depends on metaphor. We understand new or complex things in relation to things we already know.
all theory is metaphor
On the very same page of that book Gareth Morgan goes on to state a very important fact:
Metaphor stretches imagination in a way that can create powerful insights, but at the risk of distortion
Although metaphors can help us gain new insight, all metaphors are incomplete, biased and skewed. A metaphor helps us see certain things, but makes us blind to other things. Gareth’s advice is to use a number of metaphors collectively so that the different metaphors can complement each other. Allowing multiple metaphors to complement each other may not be an easy task but according to Gareth it is well worth our time.
So what metaphors can we find that are relevant for software development? I have gathered some of my favorite metaphors in this post. They complement each other in that they see the same phenomenon (software development of course) with very different eyes (remember that’s where the beauty is). Armed with these metaphors we can understand and focus on multiple different and important aspects of software development.
Building airplanes in the sky
This metaphor adds the insight that when we create software for a business that is up and running we cannot disturb their current business. We have to create and introduce software in such a way that we do not stop or disturb important business activities. This can add a lot of new considerations and therefore make our jobs more complicated. Being aware of this added complexity is a good thing. EDS made a commercial a few years back that illustrates this metaphor. The film is brilliant and only takes a minute to watch. Enjoy!
Herding cats is a figure of speech that is used to convey that a task is extremely difficult. We have an image of cats as being individualists that doesn’t cooperate very well. To bring cats together in a herd is therefore a very challenging task. In some respects creating software is similar to herding cats. Bringing a group of diverse stakeholders together and make them agree upon things can also be a daunting task. Making ideas, information and technology work well together is perhaps easier, but still a challenge. Awareness of these kinds of problems can help us prepare for the tasks and realize that we need to handle that kind of problems in order to create successful software. Again, EDS has made a very entertaining and illustrative commercial about herding cats that I really recommend viewing.
Running of the squirrels
The running of the squirrels is yet another idea signed EDS. This time the point is that for most companies the running of the bulls – that is avoiding the big and strong competitors – is not the biggest issue. Instead you need to worry about handling squirrels – the small, fast and nimble competitors. To do this we need software that is easy to change and adapt to new business requirements. Another one-minute commercial illustrates this.
The Technical Debt metaphor was coined by Ward Cunningham and is a financial analogy. Borrowing money is a quick way to get hold of new funds and indirectly other resources. As most of us know, when you have borrowed money you need to repay that money at a later time. You should also be prepared to pay interest rate. If you just keep borrowing money you will eventually have to pay so much interest rate that paying interest rates is all that you can afford. If you throw some software out there, quick and dirty, again and again, you will eventually end up in a situation where the code becomes impossible to work with unless you clean it up. The quick and dirty approach is analogous to borrowing money and you now have a sizeable technical debt. With such a debt on your hands you will be terrified to add new features to your code (since you do not really understand it), furthermore you will most likely have to spend a lot of time on fixing defects (a.k.a. bugs) to prevent your software from malfunctioning. The software development analogue to repayment is refactoring. By rewriting and cleaning up your code you make repayments so that you eventually can understand the code and work effectively with it again. In this interview Ward Cunningham explains by himself how he developed this particular metaphor.
A collaborative game
Alistair Cockburn came up with the idéa that software development is a cooperative game. In this analogy a game is to be thought of as “An activity providing entertainment or amusement” so that the competition aspects of games are reduced – but not eliminated completely. The team developing a piece of software can still be competing against other teams that develop similar software. The game is goal seeking (finishing the software) and therefore has a natural end. However, the joy of developing software is not reduced to reaching the goal. Much of the joy comes from the process of developing the software, much like rock-climbers enjoy the climb – not only reaching the peak. Also, the goal of finishing the software is a secondary goal. Secondary to things like gaining knowledge, growing the company, increasing ones influence and creating a career. Another secondary goal of the game is to create an advantageous position for the next game that consists of altering the system or creating a neighboring system. This is done by learning about the current system and creating markers or reminders of what was learned. Jeff Atwood concludes that the secret is:
learning how to play the game so that everyone is having fun
The design field is described as focusing on producing specifications that can be used to build products that are intended to accomplish certain goals under certain restrictions. This metaphor emphasizes that the process of software development is the cultivation of detailed specifications or instructions that can then be used to build programs. In both product and software design it is important that the end product is functional and that the product is easy to use and maintain. In both disciplines it is highly recommended to use proven design concepts and base the designs on the work of others. A great example of the success of this metaphor is the popularity of software design patterns.
If I missed out on your favorite software development metaphor then please comment on this post and I will update it accordingly.
Andrew Hunt and David Thomas put forward the idea that programming is similar to gardening in their book The Pragmatic Programmer. They argue that engineering and construction is very orderly but also unrealistic, and therefore not very much like software development. In gardening you would instead expect a lot of less orderly things to happen, e.g. a plant gets too big or dies, actual colors of the plants doesn’t mix well and due to its organic nature a garden needs constant maintenance or tending. In an interesting interview Andy Hunt says that
You do plan. … You’ve got a great plan, a whole design. … [but the] garden doesn’t quite come up the way you drew the picture.
This metaphor can make us see software development as something that is not as neat as our orderly plans, and be prepared to constantly work on improving the resulting software. Unlike most buildings, a software program can be changed and molded quite a bit after its initial delivery.