Metaphors to Explain Software Development

Often in the software business, you'll deal with people that don't really know a great deal about software. This is not a problem. You might have clients that come to you needing a product to be built, and they'll need advice and guidance - that's what you're there for. Similarly, colleagues in non-technical roles don't have to know a great deal about how projects are put together to do their job; that's your responsibility.

However, it's impossible to effectively communicate with the people you work with if they don't have at least a rough mental model of how the process is supposed to work. If someone has misconceptions about how a software project is built or run, you'll run into some familiar issues. Have you ever had clients unable to understand why you can't change a feature instantly? Sales promising whatever it takes to close without thought of the eventual cost? Had product managers that can't understand how short term hacks result in buggy end products? It's a persistent problem, and often caused by faulty mental models that produce unrealistic expectations.

While you can't teach someone all the subtleties of creating a software product, you can help them to understand the rough outlines a little better. Below are three useful metaphors for building software that will get you talking more effectively with people.

Building and Construction

We talk about project architecture for a reason - the comparisons of a software project to a physical structure are almost immediately apparent to someone involved with the technical design of a product. To a non-techie, the parallels are readily explained. Comparisons with a physical buildings immediately give a sense of structure. You can talk about the foundations, superstructure, electrical services and plumbing that comprise the form and function of a building. You can talk about cladding and inner partition walls - these can radically alter the look of a building, but don't require any changes to the fundamental structure.

You can also get across the idea of dependencies and change management. Change your mind during the design phase? That's doable. Parts of the building will have to be redesigned and costs will have to be figured out again, but it's certainly achievable. Change your mind when the building is halfway complete? That's a lot trickier to deal with. In the best case, changes can be artfully worked into the ongoing construction. In the worst cases, the majority of the building might have to be torn down and rebuilt. That's not to say it can't be done - just that it will be costly.

Writing a Novel

This is a brilliant way of understanding software and coding. Writing is actually very similar to coding in a number of ways, and the number of people who can write in their natural language is much larger than the number of people who can program (I make no similar assertions made about the numbers of people who can write or code well). Most people have never written a book but the difficulty of novel writing is intuitive. It looks hard. Both code and natural language are formed from written statements; although code by its nature has to be more explicit and precise, stories and code both have to follow lots of rules and guidelines to be successful.

As an analogy this works on lots of scales. An author tinkers with individual sentences in the same way a programmer refactors parts of their code. Overly wordy phrases can be made more concise, words and sentence structure can be altered to better convey a particular effect. This happens more or less continuously, as well in bursts or re-reading and re-writing.

On a larger scale a good novel has to have the structure to support itself; a compelling plot must build upon itself through the text smoothly, carefully moderating narrative pace, character development and important events. A character's actions late in the novel must be consistent with the story built up to that point; changing narrative direction near the end of the book might require going back and re-writing large portions of earlier text. Similarly, a software product has to be self-supporting on all levels - right the way from consistent design decisions down to strong coding conventions.

Painting a Masterpiece

Perhaps surprisingly, you can draw a lot of parallels between a big software project and large piece of traditional artwork. Consider an oil painting. All of the comparisons about structure hold - for a work to be a success, it must execute its subject matter with good composition, lighting, balance and depth. Background detail must support the painting's focal point but not detract from the work, movement must be suggested though the careful positioning of subjects and the work as a whole has to be stylistically consistent. Changing a painting halfway through can be done, but often means just painting over the top without making use of the original underneath.

Using artwork like this is also a great way to argue for iterative design and prototyping. Imagine an artist starting a huge, detailed 8-foot oil commission. Nobody sane would attempt a painting on such a scale without first sketching out a few studies and experimenting with different techniques. Before the artist begins they need to understand both their subject and methods thoroughly. Yet this is exactly what we see with big waterfall-style software projects - the product is specified upfront without real understanding of the problem space.

Prototyping is the programming equivalent of concept art - you can create lots of interactive experiments quickly to get a feel for the design. It also lets you show off those concepts immediately to everybody involved; if there are any misconceptions or suggestions it's much, much better to sort them out during prototyping, rather than later on in the development cycle.

Last Word

These metaphors have worked well for me in the past; I hope they serve you well too. There's always the danger that a metaphor can run away from you and take on a life of its own. Again, careful and deliberate communication is the key. If you've got any other hacks that work well for communicating technical concepts to people, let me know!