Hacker News Reader

Comment by nullspace | Hacker News Reader

> There is only one correct way to do something .... so take great care in doing it right the first time.

I hear this a lot, in various contexts, and I even used say it a lot. But this has actually stopped making sense for me. I don’t think I’ve ever genuinely seen a case where there is only one obvious way to do something, or that there’s a way that is obviously the “right” way. Everything non-trivial is chock full of trade offs and hidden corners that could make it obviously wrong in hindsight.

Does someone disagree? Can you share your perspective.

View on HN

Completely agree. I'd change this whole line to something like:

"There is never only one way to do something. You can't know which is correct, so go for the simplest option that is easy to change later"

Unless you happen to know which is correct, such as when working with a full specification.

Complete trumps simple.

(Grumble grumble when parts of protocols are ignored for not even simplicity.)

> go for the simplest option that is easy to change later

And once customers get their hands on your simple thing, management won't let you change it to something better...

(Also known as, "The demo becomes the product.")

Your simple solution is embedded in a complex social reality. If you're not taking that into account, it probably won't stay simple for long: i.e. simple to maintain, simple to operate, simple to build new features on.

This certainly seems a bit too idealistic. Not only is a problem with a single correct solution a rare thing indeed, but in my experience complexity often springs from shifting priorities and requirements for the software coming from sources outside of our control (ie, management or the client), and digging in to determine the most elegant solution is often not within the time budget for completing the project.

While I agree that simplicity is always better than complexity, in practice it is an abstract target rather than a hard requirement.

I agree with you. If there is one correct way, then software writers are fungible, and software can be built with commodity parts. I don't think this is true. If it is, then we have an awful hard time finding correct ways; just look at how many sorting algorithms there are.

> If there is one correct way, then software writers are fungible

I don't believe that follows.

For example, there is one 'correct way' to unscramble a rubiks cube, but humans unscramble them in a much more roundabout manner.

Just because there is one correct way to do it doesn't imply that all rubiks cube solvers are fungible.

This is because of the very high cognitive load of finding the correct way.

Math, especially number theory, is full of conjectures that are easy to state but take hundreds of years to resolve, and at it's base computer science is math.

> For example, there is one 'correct way' to unscramble a rubiks cube

Thats not true from a mechanical standpoint. From start, rotate an edge 180degrees. Now you can turn it right 180 or left 180.

Making 2 coins show the same face (when they differ) doesnt have one correct algorithm, in the same vein. Developers necessarily interact with apis at this level and generalize from these choices.

The integrity of my rubik's cube analogy isn't critical to my argument, but...

Even allowing for equivalent rotations as you mention, the method humans use to unscramble a rubik's cube is far far from optimal because we can't grok a scrambled rubik's cube then just execute the optimal solution.

Also this is just pedantry because WLOG you could just name those equivalent 180 rotations as a single operation anyway.

> you could just name those equivalent 180 rotations as a single operation anyway.

That isnt true insofar as there are decisions that are based on arbitrary perception and categorization. What you could do is irrelevant because that is an assumption to create a generalization. GL with whatever.

I too have flipped my position on this.

I used to be exhausted by so many libraries which all do more or less the same thing. I often imagined a fantasy penultimate implementation which would moot all the other partial or less optimal alternatives.

I now believe that each use case entails very different tradeoffs.

I now believe that fit and finish matter more than completeness.

Further, I enthusiastically support reinventing the wheel, for self study, batting practice, or just for kicks.

The thinking that there is only one correct way is very damaging. In reality there are almost several ways to do something. And each of these ways can be successful if done well or be a disaster if done wrong. So instead of constantly adjusting to reality (which is what Agile should be) we spend a lot of time on ideological discussions and less time on action.

Perhaps the author meant something like: "There is only one correct way [for a user] to do something [with your software]"?

That would kind of make more sense with the follow up remark that two ways is more complex.

Otherwise I completely agree, every non-trivial design will involve tradeoffs.

I agree that as read literally, it's too much. I interpreted the author's intent as, "there may be multiple correct ways to do something, but pick 1 simple way and enforce that being the way it's done in the future."

Reply on news.ycombinator.com