Posted by Gerbrand van Dieijen at around evening time: July 25th, 2010
People use metaphors to understand or to explain something better. Metaphors in software development are ubiquitous, as in the computer world in general. Especially people who are in the business of software development, but aren’t experienced in actual software development, often use various metaphors to better grasp what they’re dealing with. Some metaphors work, but many are more damaging then helpful.
In this posting I’ll list a few metaphors I, as a software developer, heard in recent years, starting with rather ill-chosen or understood metaphors.
- Software-development is like building (a house) - As a metaphor, building a house is as old as written history, just as, for example, a key or water. So in broader perspective, a house isn’t such a bad metaphor (‘my house shouldn’t be built on sand’).
Seeing software as something that should be built, and seeing software developers as builders is however a very ill-chosen metaphor. Software development is in essence designing. So, speaking in metaphors, software-development is like designing a house.
An architect, together with an engineering company, technical drawing company and various others designs a house. After that’s done that design can be constructed infinite times. Something that is common in the Netherlands with Vinex wijken (picture from Wikimedia commons).
The same applies to software, except you don’t need a contractor to build the houses: you just compile, build and deploy. - A car – no metaphor seems more popular than the car. People like to compare software with a car, like in the many jokes comparing a car with Windows or Apple.
The reason people like this metaphor, almost anyone has a car and uses it very frequently with few problems. When you order a new car, and specify you want a red car running gasoline and chrome wheels you’ll get that car for the price you agreed on. And when it doesn’t drive you simply return the car.
Why can’t software be the same: I specify the requirements and I get that delivered? If you’ve read the previous paragraphs you can guess what’s wrong the metaphor: Software development isn’t like ordering a car, or even manufacturing a car. Software development is like designing a car. A highly recommended book by Poppendieck, Lean Software Development explains this in detail.
Inherently for design processes, you’ll never know exactly what the outcome will be. And if you’re a customer and actually care about the outcome, you’ve got to be involved in design throughout the process, either by being present yourself as customer or someone who can represent you. In Scrum, the software development process used here at Xebia, that role is called the Product Owner.
- Software should be like electricity – it should just work. The idea behind that metaphor: software development is just a utility department, just as the the financial department, the cleaning department or help desk. Somewhere in the organization there’s a software development department that is doing the automation of our company.
However software development isn’t a utility; software development is creating a new utility. The very act of introducing new software changes your organization, the way you do business. That doesn’t contradict with the saying ‘IT should be for the business and not the other way around’: IT changes your business, for the benefit of that business.
Think of software development like designing a new device, whether a new kind of television, coffee machine or some type of sail boat. Or think of it like introducing a whole new way of doing accounting. Or introducing electric light when you’re used to gas lighting.
Complexity varies per case, but in each case software development is complex and you can’t manage software development as a utility with fixed outcome using some KPIs and a few requirement documents. Your organization, the way you do business will change when new software is introduced and you can’t predict exactly how. - A lawyer – What would software development have to do with law? The work itself isn’t very similar – similarity is in how people could or should view professionals in law:
- A lot of people study law (at least in the Netherlands), but few of them actually become lawyer at an official law firm. Similar, a lot of people have somehow learned to program, but few are actually good software engineers.
Also, a lot of mediocre software engineers do not equal one good software engineer, just as is the case you’ll have a much smaller chance to win in court when you take with you a lot of mediocre lawyers. Hiring good software engineers will eventually save you more money than by hiring cheap software engineers. - A good lawyer at the very least combines analytical skills with in depth knowledge of laws in the subject he’s specialized. He (or she) reads a lot of on other cases, legal magazines, newly issued laws, etc. He will do his best for the client, but a good lawyer won’t do literally what the client asks him too – certainly if the client asks him to do something immoral or what could be very bad for the outcome of the case.
Similar, a software engineer should focus on good end-result – creating customer value. He shouldn’t promise something immoral or impossible, like promising we’ll get this done in-time, in-budget and according to your specification’ (when the specification is, as virtually always, to vague and ambiguous in advance to promise such a thing).
When the customer asks something which is in the end bad for the end-result, such as to skip testing or leave the integration server for a later time, a good software engineer should refuse to proceed. - Finally you can become a good lawyer by first being a junior associate and working with someone who’s already a good lawyer. In software development, that could translate software apprenticeship. Until recently, there were no companies I knew of where you could become software apprentice. At a lot of software development companies you can start as a some sort of trainee/junior, but that usually meant you’d start doing maintenance, support or testing and you’re expected to pick up programming skills by yourself, or become team lead, analyst or other role where you wouldn’t need to program anymore.
Since recently, there’s an opportunity to become apprentice in software development: if you’ve just finished a BSc or MSc on engineering, love to program and develop software: go to Apprenticeship Program at Xebia.
- A lot of people study law (at least in the Netherlands), but few of them actually become lawyer at an official law firm. Similar, a lot of people have somehow learned to program, but few are actually good software engineers.
[...] This post was mentioned on Twitter by Xebia BV, Henry Cowell. Henry Cowell said: Metaphors in software development | Xebia Blog: People use metaphors to understand something or to have something … http://bit.ly/cTNQ7o [...]
Nice post!
Indeed we use metaphors to express emotion, to explain things. We use them to make our descriptions more vivid and alive and sometimes they are just used to entertain. But mostly intended to let you see what you hear, or give an image to what you read. A picture tells you more than a thousand words, isn’t it?
This is done by developers and non-developers. We use metaphors every day and some people use them all the time. Most metaphors are actually similes. They are used to compare things and start with ‘…. is like’ or ‘as ….. as’. Metaphors and similes are analogies. You use both in your post.
Unfortunately some analogies are ill chosen, I have to agree with you on that. We have to watch out for these ones, for they could be meant as smoke screens and do exactly the opposite.
As your spelling checker wasn’t ‘on’ as you wrote this post, typo’s were as common as Belisha beacons on zebra crossings. That’s a simile, as you can see
Quality without compromise. That applies to software development and to writing posts: experience = experienced, there = they are, time = times, ratter = rather, now = know, wetter = whether, then = than
Hello Mary,
Thanks very much for your comments. I wasn’t aware of the distinction between simile and metaphor. A better title could have been Figures or speech in software development, if I understand Wikipedia and Webster, although it might sound less catchy.
You’re absolutely right on writing posts. I should have proof-read my post a whole lot better. Just as with wrong metaphors, when text is grammatically ill-written, it’ll be less-understood as well.
I’ve updated my post; hopefully most of the grammar and spelling errors are gone.
good post, We are all good at something but we don’t all know what that something is. It can take a long time and many mistakes to come across something that we love and are good at. Writing english when your mother language is other than, is a great accomplishment in and of itself. You are definately Dutch and you did a great job. I read hundreds of blogs every month and your english is great. I like using analogies when I am talking or teaching others, they tend to learn more and retain it better. It is a good habit that can make you a great teacher if not an unwilling leader. I wish there were nore apprentice programs, that is how everyone learned, once upon a time, it teaches patience and deapth that a social learning evironment can’t teach. And if the mentor takes the time to do it right, like a cabinet maker, the projects come out shiny, smooth and error free. Thanks for the post, it got me thinking, and that’s good.
[...] posts:- A Metaphor in Software (http://www.daedtech.com/?p=28)- Metaphors in Software Development (http://blog.xebia.com/2010/07/25...)Also, glance at the comments in the second post.Insert a dynamic date hereView All 0 CommentsCannot [...]