It's only natural that a job that used to take 2 now takes 10 people because of those facts.
And I agree. We've traded safety and a few other things that could have been ironed out in exchange of massive gridlocks, headaches and colossal facepalms. Performance is only on par if you consider the hardware improvements, it's crazy.
Then let's say half of our profession has less than five years of experience (though I would guess it's closer to two years) -- they see what the elders do and copy that, like any good apprentice would. Suddenly, it's all they know.
Wild conjecture, of course. I would like to see it studied!
You can no longer claim to have expertise in OpenShift, Redis, Kafka and RabbitMQ and machine learning from having implemented a todo app :-(
Faced with this serious problem impacting sales, the programmers thought about it and eventually found a solution. They added... SLEEP instructions. All over the code in key points, sleep(seconds), calibrated so the response time was about the same as on ye olde CP/Me machines.
Customer reaction: completely satisfied.
... I think we can draw some conclusions on the universality of human stupidity and incentives to act that way.
Slaves don't trade productivity for their lives, they trade time.
No matter how many trillions of times more productive human activities will become, slaves's time will still belong to the masters and very little of their life will belong to them.
There is no formal theory around system design so you get people complaining about how monoliths are error prone and way too complex and you get people complaining about microservices with the exact same argument.
The result is that with a period of about a decade the industry just oscillates between the two methodologies in an endless flat circle.
Monoliths will come in vogue again in the 2020s.
Perhaps the real crux is that large teams don't build good software. Especially not from the ground up.
Another fun part is that people on the internet complain but without merit. I cannot judge some project because I usually don’t know the project. So might as well be that monolith or not team was having high attrition or there might be many other things that would affect project.
No. It goes further then this. We actually don't even know if one is better or not.
There is no formal theory that allows us to prove these designs. For example we have formal theory behind algorithm complexity that quantifies runtime cost but no such theory exists for engineering design patterns. We aren't even sure what to quantify.
But just because a formal theory doesn't yet exist doesn't mean one can be developed in the future. Until then these system designs will be like history... Always repeating itself.
I am already seeing this newly discovered love of simple, fast monoliths and the developer ergonomics they offer. What is old is new again - we are at the beginning of this cycle. The older generation learned that "complexity kills", the new generation is beginning to get it as well.