Analogies, Construction Workers and How to Derail Your Own Technology Presentation

Analogies are great for explaining complex subjects in everyday terms. A great example is the analogy that "Software Development is like building a house." That analogy comes up all the time because it seems to so aptly describe how software is written to people outside of software development. Analogies are supposed to show similarities, however, some listeners take it to be more like a concrete description.

I was once pitching a product that kept track of which features users were running in the field and reported the information back to the development team. The developer could see which features were most heavily used, which bugs would impact the most users, where to put QA and where to focus future development dollars. The message wasn’t coming across very well so I made the colossal mistake of saying it was like a code coverage tool for features in that it told the developer how many times a feature was used, by how many users and so on.

"Code Coverage" has a very specific set of features, like method and line number execution counts. I immediately started getting questions like "Why don't we just use Clover?" You can safely insert every code coverage product you ever heard of in place of Clover and I can assure you it got mentioned.

I spent the next twenty minutes explaining how the application was not actually code coverage but like a code coverage product. Everyone fixated on the term "code coverage" and consequently the product was only seen as my spin on code coverage. Various insights on how other code coverage products would be hard to compete against, the various features of great code coverage tools, whether it would integrate into Eclipse, etc.

I left the meeting knowing that it was a complete failure. My jaw was clenched so tightly that I thought I was about to bite through my teeth. I had used an analogy that completely derailed my presentation on a technology that could accurately detect feature use in a deployed application. I now avoid using analogies like a rat avoids a cat.

I recently had an odd situation where someone went back to the old analogy of "software development is like building a house." This analogy is pretty safe when on a golf course trying to make polite conversation with someone completely outside of technology. It is such a good analogy from 50,000 foot level and it really does explain how many people can be involved in a project and their roles.

When it creeps back into the office is how the milk gets spoiled. First, software developers are not construction workers. I'm not intending anything negative toward construction workers at all. The process for becoming a skilled carpenter, electrician, plumber and several other trades, is managed through unions, guilds, licensing and other regulatory systems for ensuring that a given trades person is certifiably skilled in a particular field and can actually be found liable in cases of negligence. An electrician, for example, is actually a skilled carpenter too. A carpenter could unseat and seat a toilet if it wasn't that flood damage, and other less enjoyable aspects of the operation, make the process less appealing. Nonetheless, trades people often have a big range of skills.

Software developers are different from construction workers in that we can still go off and write components well outside our specific niche. A hibernate developer can still write a JSP and not be in any risk. We are encouraged to show our complete range of skills and exercise them daily.

The idea of designs, requirements and even the term architect appear to be taken directly from the construction realm. The concept of plans and requirements are similar but far more complex in software development as a design must taken into account a wide range of users and manage a variety of input sources while a house generally has a limited number of users and consequently an entirely different bug domain. Perhaps software development is more like building a stadium or an airport?

Production problems between houses and software development are entirely different. You are not often going to run into a house that has an error which may require a major redesign. Again, think stadium type issues, such as a drainage problem, could require a massive amount of work to resolve, so may an application's database run into scalability issues and have an equally lengthy process too.

The most negative aspect, to me, about the analogy of "software is like building a house" is when management starts to believe it. While the analogy encourages planning, it also encourages micromanagement (as some home buyers will watch the building process like hawks and sometimes with good reason) and can creates odd expectations on production delays.

This scenario can be especially troubling when a person outside of normal technology spaces decides to try to get a grip on the subject. Consider Senator Ted Steve's analogy of the Internet being a series of tubes as an example of how detrimental an analogy can be.

The core of the problem is that analogies are often misleading and far too open for interpretation. While they can be a great tool for explaining a complex topic, they are also an excellent mechanism which a listener’s mind can lock-on to and never release. This obviously perverts any message that you may have had all thanks to a well intentioned tool to help the audience. Yep, one bad analogy and soon your presentation is like a chicken with its head cut off- your message is out of control and is making one hell of a mess.

Metaphors and similes can be just as confusing, overused and mixed-up.