Random Code

When discussing concepts in the software development space, we resort to metaphors to compare the concept to something in a different, well known, area because we lack the appropriate ( or shared ) vocabulary to communicate the concept. These metaphors (technically similes) always fail at some point and that is due to something that few (if any) other professions face.

When you visit your mechanic to discuss a problem with your car and tell him about the weird clicking noise it makes when you turn hard left or right, he knows this usually means a dead CV joint.  When you visit your local software developer and ask them to build you a system to show your clients various reports about half hourly meter data,  he will look at you quizzically and ask “What’s half hourly metering?”

This is the key difference between a mechanic and a software developer, you talk to the mechanic about a problem in a domain he understands well, all he has to do is ask the right questions to understand the problem.  You talk to a software developer about a problem domain you understand well, and he has to first understand enough about the domain to be able to ask the right questions.

Software development covers a wide range of job roles, but they all exist to create a limited representation of the clients problem domain in a virtual space (hopefully to solve a problem).  I can’t think of any other professional group that faces this challenge, and the metaphors we use for software development all fail at communicating this to the people we are talking to:

Before I can solve your problem, I must first understand the problem domain