Do the simplest thing that could possibly work

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.

I mean, I think I agree more with this sentiment than most. These overly general statements tend to not have much nuance, and do little to incorporate context.

But also keep in mind the audience: the kinds of people who are tempted to use J2EE (at the time) with event sourcing and Semantic Web, etc.

This is really a counterbalance to that: let's not add sophistication and complexity by default. We really are better off when we bias towards the simpler solutions vs one that's overly complex. It's like what Dan McKinley was talking about with "Choose Boring Technology". And of course that's true (by and large), but many in our industry act like the opposite is the case - that you get rewarded for flexing how novel you can make something.

I've spent much of my career unwinding the bad ideas of overly clever devs. Sometimes that clever dev was me!

So yes ... it's an overly general statement that shouldn't need to be said, and yet it's still useful given the tendency of many to over-engineer and use unnecessarily sophisticated approaches when simpler ones would suffice.

I was initially annoyed at parts of the article, but it does point out that "hacks" often adds hidden complexity that isn't simple so there is a clarity about the tradeoff.

Now the problem with the headline and repeating it is, when "just do a simple thing" becomes mandated from management (technical or not), there comes a certain stress about trying to keep it simple and if you try running with it for a complex problems you easily end up with those hacks that become innate knowledge that's hard to transfer instead of a good design (that seemed complex upfront).

Conversly, I think a lot of "needless complexity" comes from badly planned projects where people being bitten by having to continuously add hacks to handle wild requirements easily end up overdesigning something to catch them, only to end up with no more complexity in that area and then playing catchup with the next area needing ugly hacks (to then try to design that area that stabilized and the cycle repeats).

This is why as developers we do need to inject ourselves into meetings (however boring they are) where things that do land up on our desks are decided.

I see your point, but, taken to the extreme, all it leaves us with is "everything is a trade-off" or "there's no free lunch".

Some generalizations are necessary to formalize the experience we have accumulated in the industry and teach newcomers.

The obvious problem is that, for some strange reason, lots of concepts and patterns that may be useful when applied carefully become a cult (think clean architecture and clean code), which eventually only makes the industry worse.

For example, clean architecture/ports and adapters/hexagonal/whatever, as I see it, is a very sane and pragmatic idea in general. But somehow, all battles are around how to name folders.

It’s Rich Hickey’s “Simple made Easy” all over again. “Simple” is not the easy path. Simple (or simplex, unbraided) describes an end product with very little interleaving of components. Simplicity is elegant. It takes a lot of hard work to achieve a simple end product.

I completely disagree with this being a red flag. It would be a huge green flag for me. The easiest thing to do is to create a complex system, making a simple one is difficult.

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.

From the article....

"real mastery often involves learning when to do less, not more. The fight between an ambitious novice and an old master is a well-worn cliche in martial arts movies: the novice is a blur of motion, flipping and spinning. The master is mostly still. But somehow the novice’s attacks never seem to quite connect, and the master’s eventual attack is decisive".

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.

I don't think I would go far enough to say that it's generally a red flag...

I see people adding unnecessary complexity to things all the time and advocate for keeping things simple on a daily basis probably. Otherwise designers and product managers and customers and architects will let their mind naturally add complexity to solutions which is unnecessary.

Did you read the article? It’s mostly about the nuance of how to apply this philosophy in practice, not a pithy one-size-fits-all statement about all software engineering.

“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

I was about to say the same. One of the best software talks of all time.

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.

> 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.