←back to thread

Do the simplest thing that could possibly work

(www.seangoedecke.com)
1070 points dondraper36 | 5 comments | 29 Aug 25 19:05 UTC | HN request time: 0.692s | source
Show context
sfpotter ◴[29 Aug 25 20:36 UTC] No.45069112[source]▶
Generally speaking, when I hear people say this, it's a huge red flag. Really, any time anyone puts forth any kind of broad proclamation about how software development should be done, my hackles go up. Either they don't know what they're talking about, they're full of shit, or both. The only reasonable thing to conclude after lots of experience with software development is that it's hard and requires care and deliberation. There is no one-size-fits-all advice. What I want to see is people who are open-minded and thoughtful.
replies(8): >>45069256 #>>45069351 #>>45069358 #>>45069645 #>>45069655 #>>45069794 #>>45070229 #>>45070818 #
1. alphazard ◴[29 Aug 25 21:33 UTC] No.45069655[source]▶
Simplicity (meaning the inverse of complexity) is usually the most important factor when considering two possible ways of doing something with software. And this is because it has to be conceived of, pitched to, agreed upon, built, and maintained by humans.

Unfortunately, simplicity is complicated. The median engineer in industry is not a reliable judge of which of two designs is less complex.

Further, "simplicity" as an argument has become something people can parrot. So now it's a knee-jerk fallback when a coworker challenges them about the approach they are taking. They quickly say "This is simpler" in response to a much longer, more sincere, and more correct argument. Ideally the team leader would help suss out what's going on, but increasingly the team lead is a less than competent manager, and simplicity is too complicated a topic for them to give a reliable signal. They prefer not to ruffle feathers and let whoever is doing the work make the call; the team bears the complexity.

replies(2): >>45069869 #>>45072526 #
2. melenaboija ◴[29 Aug 25 21:54 UTC] No.45069869[source]▶
Yes, and when it’s time to implement something by default, you always choose "your optimal". If you have two options that solve the problem equally well, you always choose the simplest, among other things because it’s shorter.

What you really learn over time and it’s more useful, is to think along these lines: don’t try to solve problems that don’t exist yet.

This is a mantraic, cool headline but useless. The article doesn't develop it properly either in my opinion.

replies(1): >>45077914 #
3. johannessjoberg ◴[30 Aug 25 07:03 UTC] No.45072526[source]▶
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

― Dijkstra

replies(1): >>45073555 #
4. Arisaka1 ◴[30 Aug 25 10:39 UTC] No.45073555[source]▶
I hate how true this is, even as a job seeker. I'm here building things using Next.js when I'm fully aware that I can build them using less than that, yet I must keep going and overcomplicate things in order to add my familiarity with specific technologies with my personal projects on my resume.

And then, there's people who do "resume-driven development" and push for more complexity in their workplace so that they can list real-life work experience for the next door to open. I know someone who made a tool that just installs Java JDK + IDE + DBearer using Rust, so that he can claim that he used Rust in the previous company he worked for.

I generally think we're more obsessed with being perceived as engineers than actually do engineering.

5. internetter ◴[30 Aug 25 20:54 UTC] No.45077914[source]▶
> is to think along these lines: don’t try to solve problems that don’t exist yet.

It is best to prepare for problems which don't exist yet. You don't need to solve them, but design with the expectation they may arise. Failure to do so leads to tech debt.