When I need to explain a complex idea, I often use an analogy. This helps convey concepts to people from different disciplines, too.
One thing I learned is how important it is to choose the right analogy.
A colleague recently used car design as an analogy to software development.
This analogy was fundamentally wrong on several levels. First off, cars are a solved problem, for the most part. This gives designers the freedom to focus on appearance. Then, there’s the fact that once produced, the manufacturer cannot make big changes to it.
There are plenty of other differences. This matters because choosing the wrong analogy could lead to the wrong conclusions.
In our case, the confusing analogy led my colleague to suggesting we should develop the UI first, and worry about the internals later, like putting the engine into a car after designing its “shell”.
In software, the UI is usually the easy problem. Without working internals, it is useless. We should focus on the hard problem first. We then give ourselves more time to do it right. It also means our solution can be UI agnostic. This will allow us to change the UI fairly significantly later on without changing the underlying logic.
There was a good lesson there for me. You have to choose your analogies well. Otherwise you’re like a cricket trying to draw water out of a plutonium well. That never ends well.
Optimising My Life 