Problem with Software Metaphors
Sometimes it's difficult to explain software to "non-software" people. Luckily there are metaphors. We can compare software development to things like construction, gardening, or writing to help others understand what we do.
Metaphors can also help your own learning. The way I learned the difference between a class and a class instance was imagining classes as architectural drawings and class instances as different houses built following those drawings.
However, metaphors have their limits. And when stretched to their limits, metaphors start to break down. You can also hinder your own thinking if you rely too much on metaphors.
Let's talk about analogies and analogical arguments and reasoning. Analogies are comparisons between different entities. A metaphor is one way to communicate an analogy.
When you make an argument from analogy, you start with perceived similarities and then continue to infer further similarities that have not yet been observed. Here is the more general form of analogical argumentation:
- S is similar to T in a, b, and c.
- S is perceived to have feature z.
- Therefore, T also has the feature z.
We use analogies constantly as the basis of our reasoning. There's nothing wrong with it (you can find examples of analogical arguments used successfully in science here https://plato.stanford.edu/entries/reasoning-analogy/).
The problem is that sometimes we might end up with arguments that aren't actually valid if we base our reasoning solely on analogies. Here is an example of that: Writing software can be like construction. Should we therefore avoid writing code during winter months?
We can easily spot the problem with the previous example (software isn't built on top of actual ground and therefore we don't need to care if the ground is frozen or not). But could the following argument slip past you in a meeting when you haven't had your first cup of coffee: "Imagine starting to build your house without blueprints! We can't start this project until we have a detailed plan for our software architecture."
How about the effect metaphors and analogies can have on your own thinking and reasoning? Instead of figuring out what is actually true, analogical reasoning can be the easy way out when you're faced with a difficult question. Pattern matching comes naturally to us. But this doesn't mean that we shouldn't make the extra effort to every now and then start our reasoning from fundamental truths or first principles.
For a second, stop imagining how software development is like building a house. Instead, look at the people in your project and study what they do. Observe how the code actually evolves inside a codebase. Focus on reality and allow it to teach you.