TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Bad Metaphors You Encounter When Defending Your Design Decisions

3 pointsby JASchilzover 1 year ago
Hi HN! As a senior software engineer, I have to defend my design decisions from time to time. While discussing design, I&#x27;m fairly comfortable addressing specific technical questions or critiques. But sometimes I find that I get de-railed by a metaphor and don&#x27;t realize the right response to that metaphor until hours after the meeting.<p>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&#x27;t apply very well to the situation at hand or even make any concrete point, but if I&#x27;m not able to address the comment it seems to onlookers as if it must contain valid criticism.<p>And so I&#x27;m wondering if you can share some poorly applied metaphors that you&#x27;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. :)<p>My hope is that by reviewing this list, I&#x27;ll be better prepared to quickly address these metaphors when I encounter them in the wild.<p>I&#x27;ll start with an easy one! &quot;Let&#x27;s not re-invent the wheel.&quot; The suggestion is that the proposed design unnecessarily re-does a lot of work that&#x27;s already done by some other solution. I tend to encounter this either when someone isn&#x27;t really familiar with the problem domain I&#x27;m trying to solve and assumes that it can be solved with some existing solution, or when they&#x27;re not familiar with the tech stack I&#x27;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&#x27;s possible to move the conversation forward by focusing on the specific relative costs or benefits of any proposed alternatives.<p>Thanks for your thoughts!

no comments

no comments