Every person have a limit on how complex abstractions they're able to properly create. Then there is another, usually lower, limit for what kind of abstraction they're able to understand well enough to make use of it.
In a lot of cases, people try to leverage abstractions above that second level (for them), in which case they're simply imitating in a cargo cult manner some abstraction that will often not work well if not properly understood.
This is where the atrocities start, imo.
And the sad part is that many of these programmers do have a fairly good understanding of the business needs of the stuff they're making, and often those things are quite simple from a technical perspective.
Programmers that might have been able to create perfectly usable apps in VB or something similar 20 years ago, are now only churning out useless garbage in some moder cloud based stack. (Or, at bes,t are using 80% of their time struggling with their tech, while with a simpler setup, they could have spend only 20% on the tech and used 80% of their attention on addressing business needs.)
I don't think intelligence or lack thereof is the problem. Rather, it seems people are paralyzing themselves by enjoying the endless discussions, stakeholder indecision, or boredom. All leading to these grotesque things which lack words in the right places, but have plenty in the wrong places.
The average web dev CRUD job isn't interesting enough to warrant that much intelligence.
Intelligence is definitly a factor. In fact, more often than not when I encounter a person or team that seem to spend their time on everything else except addressing their most important problems, the reason for the apparent procastination is that they simply do not even know how to START solving the problem.
This is not exclusive for developers. It happens in management, too. Which is a second source of the problems you describe.
my experience is quite the opposite, it's much more difficult to create a simple abstraction as opposed to an overengineered and/or overgeneralized one.
sure, but it's easier to solve a complex problem by building an abstraction that is more complex than the problem requires, that to build an abstraction that is as simple as possible (given the complexity inherent to the problem). then, once you have your too-complex abstraction, it can be difficult to restrain yourself, especially as an eager junior developer, to not take your amazing feat of abstraction engineering to its logical, generalized conclusion... or at least die trying.
"see, now, every time I want to do x, all I have to do is y and z, instead of a, b, c, and d" is an incredibly addictive drug! (I write this as a recovering addict.)
right, but my point is thats what we call a bad software developer. and most software developers are warned, because real abstraction is beyond their capability. a world class software engineer knows that maxim, but also is capable of building an abstraction that lasts.
