I think it's easy to state this sort of opinion, it sounds good on the surface, but I don't feel it stands up to scrutiny. I'd like to see some evidence or studies done to see if this is actually a trend.
Simple solutions are good enough some of the time, perhaps even most of the time, but often fall down with edge cases. But edge cases add up, and dealing with them is complicated.
For example, calculating pay for hourly paid workers is a "simple" problem. Deduct start time from end time and multiply by rate. Covers 90% of the workforce.
But the other 10% take much more work. That team that rotates an on-call worker (which earms an allowance), who gets a call (first hour is free, next is double time etc.)
So it is with software. Adding 2 numbers is trivial. But what about overflows? What about underflows? What if one number is infinity? What if it's i?
The simple solution is "just add, ignore edge cases". The complex solution handles the edge cases. Which is better in the long run?
Unnecessary complexity is a microservice architecture to do the same thing.
Would you want to be in charge of simplifing this architecture for a 'senior staff' title for 4+ years?
This is just one of many examples who have this sort of complexity and it is celebrated, and the microservices hype (originated from Netflix and overhyped by Thoughtworks) have somewhat caused this madness and for some, it has turned into a mountain of technical debt to maintain.
Unless you have a very good reason to save a company from drowing over it's own complex infrastructure costs to run itself, attempting to simplify this architecture will be met with feroucious backlash by other teams of senior staff engineers, hundreds of meetings with risk officers and being blocked because of forever meetings with architects.
This isn't an engineering problem, it's a sales problem.
Also, you don't even have to be good at this stuff anymore. Any management nitwit would eat that up on a performance eval, and I had GPT write it for me.
Prompt: "Write up the most corporate self eval possible for someone who identified a simple solution in only 50 lines of code, instead of creating an over architecture mess. Keep it to just three sentences"
The only valid excuse is whether the risk is worth it vs the potential gains. But the solutions that I prefer are the ones that offer minimal changes with massive gains rather than co-ordinating with hundreds of teams for years over an unrelated change.
If you have to do the latter for a tiny code change, then the architecture was most certainly built on a bad foundation, riddled with hundreds of brittle moving part waiting for an incident.
At first people were like "Well, you didn't do much" but when they saw the value things changed drastically. It's a bit of marketing you have to do to help bring people along.
Often perceived impact is correlated with complexity, sadly.
Don't feel sorry for me though, they still paid me well enough, and I'm happily doing my own stuff now :)
As a practicing architect (of buildings) I had a special fondness of working on minimalist projects. Buildings are a complex problem space. You typically can't design out unnecessary complexity entirely. So you have to work backward from goals (the finished condition) to infrastructure (the building structure) to figure out how to make the end product look like almost nothing (Mies's "beinahe nichts").
That's all to say that "complexity impresses" as the article says, but the discerning understand that simplicity can be even more impressive.
It also puts me in the frame of mind of another famous one - Fred Brooks's "No Silver Bullet" [1] and the idea of essential vs. accidental complexity. Or as I like to think of it in a slightly more nuanced way - not necessarily "accidental" but at least "incidental."
[0] https://www.folklore.org/Negative_2000_Lines_Of_Code.html
[1] https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
The best engineer I know who can work with huge complex systems in a big company usually starts with a complex solution then after he understands what he wants to achieve thinks backwards and reimplements it in the fewest possible lines of code change with the already complex system.
cyberax•48m ago
I also promote and advocate for people who push for simple solutions with as little infrastructure as possible.