The Perils of the Wrong Metaphor in the World of Software

Image via  unsplash.com

Image via unsplash.com

I blame ‘software engineering’. When it was called ‘computer programming’ nobody except us nerds knew or cared what it was. To the uninitiated, it was a dark art best not talked about. But some of us weren’t happy with that and wanted to be considered ‘serious professionals’. This is why ‘software engineering’ was born. And this is where all of our troubles began…

Now, people who didn’t know anything about computer programming may hear the word ‘engineering’ and assume that’s about building houses or bridges. “I’ve had an extension built on my house, I know something about that,” they think. Before we knew it, the rot had set in.

THE CONFUSION

The problem is that, at a glance, writing software does look a lot like engineering. Enough so that you could be forgiven for mistaking the two. You create specifications which are like building floor plans and coding is often described as ‘building’ software. Maybe you have heard about ‘code reuse’ or ‘frameworks’? They sound suspiciously like the prefabricated components they build skyscrapers out of. It’s no wonder this brings about such confusion. 

WHY IS THIS A PROBLEM?

Unfortunately writing software only looks like engineering. For example, when building a house your floor plans lay the foundations - the rooms, doors and windows - all the features that you want. Then from these plans, the house is built. To the uninitiated, this is an attractive way of thinking about how software is made; it’s specification based, it’s predictable, its standardised, and it’s completely wrong. 

The guilty secret of ‘software engineering’ is that it’s incredibly messy, nothing fits together properly, nothing looks like its specification (assuming you had one), requirements are poorly understood and they change fast. And no two jobs are the same anyway - no matter how similar they look.

THE ROOT OF THE ISSUE

Let’s get to the real root of the issue. It’s because we’ve been living in houses for around 11,500 years and building software for only around 50. The user needs behind a ‘house’ are well understood and encoded into architectural patterns. Although needs can vary (extra rooms for the kids, somewhere to park the car etc.) they don’t vary enormously. Well known patterns are followed. 

This is the point where the metaphor breaks down: user needs are often one of the least understood aspects of building software. When a carpenter builds a door or window frame, while there may be a few new details, they are not typically re-inventing the notion of ‘window frame’. In software, on the other hand, it’s often the case that everything will get re-imagined.

Even when you are building something similar to a previous project there will be many small changes that inexorably ripple out through the design and create new problems, new complexities and new decisions. And these changes can happen right in the middle of the project - you may have started out building a 2-up 2-down only to find yourself adding a new floor, atrium, and wine cellar.

When you are building software the only certainty is uncertainty - the only constant is change.

IN SEARCH OF A BETTER METAPHOR 

A metaphor I’d like you to consider is a law suit. It’s likely to be expensive, risky, and conducted in a language you don’t understand. The facts of every case, however superficially similar, are always different and can have a strong bearing on the outcome and your case needs to reflect that.

To craft a good case you need expensive experts - lawyers - to build it for you. They are versed in the complex beast that is the law and use their knowledge and experience to make the best case out of the available evidence and precedent. They may specialise in an area of the law but still know that every case is different and has its own problems.

If you hire good lawyers, listened to their advice, and build a strong case then hopefully you win. But, if the situation arose again you’d likely think long and hard about the cost, the risk of failure, and how best to ensure you’ll get a good result.

It would be wise to apply the same approach to building software. Understand that it’s complicated, no two pieces of software are the same no matter how similar they look and it’s all done in a language you don’t understand.

There are many traps for the unwary - don’t get caught. Hire good people and listen to their advice.

Find me on LinkedIn Follow me on Twitter Join my Mailing list

Matt Mower