And this is where things get dangerous.

Sometimes the line between analogy and reality blurs. Metaphors can make us value things that aren’t that important while undervaluing the things that are.

When we take these comparisons too far, we don’t make our best decisions. Metaphor has a devilish way of blinding us to the truth. Our decisions might make perfect sense in the context of the metaphor, but when stripped down to just the business of building applications, we can easily be led astray. We sometimes rely on the perceived benefits of the metaphor too heavily rather than paying attention to the reality of the situation.

For instance, we often use traditional architecture as a metaphor for building software. After all, it’s the origin of most of our organizational titles. That’s why we call ourselves software architects, information architects, senior developers, junior developers, and project managers. That’s why many of us still swear by wireframes, specifications, workflow diagrams, Gantt charts, and waterfall development. We’ve built a large portion of the software development process by piggybacking off of another industry.

While these concepts are essential in another medium and they have some merit in our world as well, they can just as easily imprison us. If we stop to think about why we approach a problem in a certain way, we might be able to trace its origins to following the metaphor of traditional architecture (or another metaphor) too closely.

So, how has metaphor hurt us? Let’s look at a few examples where we’ve stretched a concept from real architecture into a less-than-ideal fit for software.