Ask HN: Bad Metaphors You Encounter When Defending Your Design Decisions
I think that part of the problem is that metaphors can imply a lot without bringing enough specifics explicitly to the surface of the conversation for me to really address. Often the metaphor doesn't apply very well to the situation at hand or even make any concrete point, but if I'm not able to address the comment it seems to onlookers as if it must contain valid criticism.
And so I'm wondering if you can share some poorly applied metaphors that you've encountered while defending your software design decisions, or from any other similar situation, along with a discussion of the weak points of that metaphor or other ways to address it. Bonus points if you can provide advice for how to productively address the underlying concern. :)
My hope is that by reviewing this list, I'll be better prepared to quickly address these metaphors when I encounter them in the wild.
I'll start with an easy one! "Let's not re-invent the wheel." The suggestion is that the proposed design unnecessarily re-does a lot of work that's already done by some other solution. I tend to encounter this either when someone isn't really familiar with the problem domain I'm trying to solve and assumes that it can be solved with some existing solution, or when they're not familiar with the tech stack I've chosen and assume it must be exotic or novel. The metaphor tends to break down in that there are lots of different kinds of wheels in the world, and making a new software product is more like making a new kind of wheel than re-inventing wheels entirely. And it's possible to move the conversation forward by focusing on the specific relative costs or benefits of any proposed alternatives.
Thanks for your thoughts!