I find such laments annoying, because they're full of obvious platitudes. It's easy to sound smart quoting Einstein and Dijkstra. It's cheap to make generalizations, and point fingers at complex solutions when having both the benefit of hindsight, and ignorance about their true requirements.
"as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs. Maybe it is easier to focus on maintaining one complex database, than to have 3 "simple" ones, and triple admin work, and eventually end up having to sync them or implement distributed transactions.
Something simple to implement now may cause complex problems later. A simple off-the-shelf solution that doesn't fully solve the problem will breed complex workarounds for the unsupported cases, and eventually add complexity of migrating to something adequate. If you didn't correctly predict how a solution will fit all your requirements, you should have simply listened to Einstein.
All the advice to "just" do something "simple" is blissfully unaware that these solutions are not panacea, and it's rarely a plain choice between complex vs simple. Projects have constraints - they may need to work with existing messy systems, inconsistent legal requirements, or changing business requirements. They may prioritize time to market, or skills they can hire for. And there's brutal economics: maybe annual report export is a Rube-Goldberg machine, but it's done once a year, and a rewrite wouldn't pay for itself in 50 years.
The discussion about complexity rarely acknowledges that projects and their requirements grow, so something perfectly simple now may become complex later, in a perfectly rational way, not due to incompetence or malice. Storing data in a plain text file may be beautifully simple in the beginning, and become a bad NIH database later. But starting with a database for 3 rows of data would be overcomplicating things too. And there's cost to refactoring, so always using the ideal solution is not that simple either.
You and I would think the platitudes are obvious but I've been at tables with people where stating those made people blink with that unnamed dread that hits you when you realize you haven't understood something super simple for a very long time and are just now getting it for the first time. That happened... a number of times in my life and career.
Truth is, much less things are as obvious as you and I think.
> "as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
Nah, that's obviously (heh) a non-sequitur; iteration always beats planning. We know it by practice.
> In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs.
That's why you don't ask for permission, you ask for forgiveness. :) Another law of our profession, if not in many others too.
I didn't mean agreement as permission, but as having the same judgement. One person may say bash is the simplest, another that Makefile is even better, and third person will say they'll both become a mess, and it's simplest to use Python from the start, and so on.
Reasonable people may disagree where is the line of "but not simpler". Something that is "simple" to one person, is "primitive" to another.
If someone says they have a simple and elegant solution, but it requires their skills, is it really simpler than a "dumb" solution that more people can understand? (e.g. DB vs Excel? C vs JS?).
Everyone may be in agreement that things should be super simple, but there may be a choice between simplifying implementation vs simplifying operations. Or people may disagree about future requirements and argue that a solution that is the simplest now will hit a complex scaling problem later, and the total-lifetime-complexity of the product will be minimized by another solution instead.
Some complexity is inherent to the problem, but most seems to be incidentally introduced by the realities of deployment (non-functional), configuration (functional) and chaos monkeys (users). There is a particular 'breed' of incidental complexity I see with space cadets and front end developers for sure. Complexity is complex lol.
Outsiders don't see what happens inside companies.
A solution may need to integrate with in-house frameworks and billing (and you'll die trying to make billing simple).
A feature may get added for a big customer, and be warped by their requirements.
A feature may need to be implemented in a hurry (taking on tech debt) to win a bid/contract.
Conway's law shapes implementations - the right team to implement a thing simply may be busy with something more important, so another team will need to work around them.
In such situations the obvious simplest solution may not be available, and you either do what you can given the constraints, or fail to meet business' requirements.
Oh, I absolutely agree that there are all kinds of constraints when dealing with real world problems, including non technical ones like time constraints and expertise level. But those constraints are never documented and communicated when the resulting complex artifact is released, which causes a lot of unpleasant surprises for users. That's the reason why many engineers avoid such artifacts to mitigate the risks.
"as simple as possible, but not simpler" is always right. Messy solution? You should have made it simpler. Primitive solution causing problems? You weren't supposed to make it too simple. Why didn't you think about making it just perfect?
In reality, it's very hard to even get people to agree what is simple, when solutions have various trade-offs. Maybe it is easier to focus on maintaining one complex database, than to have 3 "simple" ones, and triple admin work, and eventually end up having to sync them or implement distributed transactions.
Something simple to implement now may cause complex problems later. A simple off-the-shelf solution that doesn't fully solve the problem will breed complex workarounds for the unsupported cases, and eventually add complexity of migrating to something adequate. If you didn't correctly predict how a solution will fit all your requirements, you should have simply listened to Einstein.
All the advice to "just" do something "simple" is blissfully unaware that these solutions are not panacea, and it's rarely a plain choice between complex vs simple. Projects have constraints - they may need to work with existing messy systems, inconsistent legal requirements, or changing business requirements. They may prioritize time to market, or skills they can hire for. And there's brutal economics: maybe annual report export is a Rube-Goldberg machine, but it's done once a year, and a rewrite wouldn't pay for itself in 50 years.
The discussion about complexity rarely acknowledges that projects and their requirements grow, so something perfectly simple now may become complex later, in a perfectly rational way, not due to incompetence or malice. Storing data in a plain text file may be beautifully simple in the beginning, and become a bad NIH database later. But starting with a database for 3 rows of data would be overcomplicating things too. And there's cost to refactoring, so always using the ideal solution is not that simple either.