Being a software developer, we’ve all experienced a time in which we had to explain a technical matter to a non technical co-worker, manager, or customer. This, as we know, is not always an easy task to say the least. Software development can be complicated and individuals not concerned with the technical aspects don’t speak the technical language that we all use. It is our responsibility as the technical professional then to be able to elucidate our ideas to them to provide them some understanding and insight.

People tend to only understand what they can see. For most people it is difficult to grasp more abstract matters without somehow visualizing them. Software is an example of such an abstract matter.
So what do we do???
Well one idea that comes to mind would be to use metaphors. Metaphors are perfect for this situation because metaphors allow you to bridge the gap between something you understand thoroughly and something you understand poorly. Leveraging the power of metaphors your will quickly (depending on the quality of the metaphor) be able to elaborate your technical software jargon into a model that your listener will be able to understand and relate to.
I think this will be clearer with an example. Let us visit the process of developing software through a comparison with physically building something. This analogy is typically used because most people are at least relatively familiar with building something sometime in there life, whether it was a Lego tower, doghouse, swing set, residential house, or even a skyscraper.
Along those lines, people are also familiar with some of the basic concepts that are involved in these matters. For example, even if a person has not built a house on their own before, they still understand that the walls and floor have to be built before you start painting or laying down carpet.
This basic and almost universal understanding is exactly what we are looking for. We can now take concepts completely foreign to the listener and apply them to ideas that they do understand.
I’ve used this metaphor before to explain the reasons behind paying for a development tool or a third party library. Many times a manager who is not technical cannot understand why a development team is asking for “X” amount of dollars to pay for code written by another company or developer.
“Why wouldn’t you just write it yourself???!” they complain. “We hired you to develop, not give you money to pay for code or use open source code developed by someone else!”. If you do not come from a technical background this might seem like a perfectly valid point, and sometimes it even is, but many times this is the wrong attitude to have. Let me explain…
When a construction worker is building a house, does he cut down the trees and shape them into lumber? Does he build his own tools from scratch? Does he build the windows, counters, toilet, dishwasher, dryer, laundry machine, or refrigerator? No. Of course not. In many cases the carpenter doesn’t even build the cabinets. Often these come pre-assembled and the carpenter just has to know how to hang the cabinets. Why is this? Could a carpenter build a cabinet? I would sure hope so. So why doesn’t he?
In building a house, you wouldn’t try to build things you can buy already built. This is because even though sometimes the materials you are buying can be expensive, the main expense is always labor! The same goes for software. If something is complicated enough that it is going to take more than a month to build from scratch and there is already a pre-built solution that completely satisfies your needs, then it makes more sense to spend the two grand on a software product than to pay your developer twice that much at least for his hours developing it from scratch.
Now I know that many people will disagree and say that the solution should be tailored to the business, and this is definitely sometimes the case. Just as it is sometimes the case that an individual will want to have everything in there house custom made. But guess what? This will cost them much more, just like it would to have a developer develop their own robust object relational mapper.
The same goes for tools that developers use. Would you want your carpenter to be stuck with just an old hammer? Or would you want him to get the job done faster (and cheaper) with a nail gun?  I relay this metaphor to managers when they won’t pay 100-200 bucks for some simple tools (ReSharper for us .NET guys 🙂 ) that would greatly increase a software developer’s productivity. The cost of the tool comes out to be what you would be paying the developer for about a half days work, yet almost always you are going to get much more value than that out of spending the money on a tool that will help the developer crank out a bunch more quality lines of code.
The building-construction metaphor could be extended in a variety of other directions which is why the metaphor is so powerful. Many terms common in software development derive from the building metaphor: software architecture, scaffolding, construction, foundation classes, and many many more. Use these metaphors to your advantage so that you aren’t stuck with a listener that has no clue, and now no more interest, in what you are talking about.
I hope you enjoyed this article and if you did please subscribe to my blog at If you don’t feel like doing that (darn you!) then I would really appreciate it if you liked or shared the article to other developers that you think would benefit from it! Thanks for reading!