Metaphors in software development

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 services are 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.