I share this frustration, but I think the root cause of the frustration is the difference between what I feel should be important, and what actually is important to people.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?
The psychological aspect of consultants and even employees trying to play a game with billable hours aside, a lot of developers of all ages genuinely feel using frameworks to do the exact same thing one can achieve with far less hubbub is a good thing, and they have trouble defending it. It's a cargo cult by all standards.
Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.
I think the issue is the batteries included approach taken nowadays.
Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.
Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.
Why reinvent the wheel? I’ve seen “architects” who didn’t think they needed Entity Framework and went about solving the same problems (mostly around change tracking) very badly. Give me a widely supported framework any day over a badly written unsupported in house solution.
Sometime frameworks are a real help, sometime using it is just making thing bloated and it's hard-linking the future to someone who have the knowledge of the framework.
I would much rather “hard link” the future to a publicly available documented framework than one that a single person who thought their problem was a special snowflake wrote.
Which is why I've been paid good money to both maintain and bring up to speed old RoR applications that were so out of date you had to manually patch the C libraries just to get it working.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
In medium and large organizations, manager pay and influence is mostly related to the number of employees managed and the size of their budget. Managers maximizing these two variables explains a lot of behavior that seems unreasonable to employees.
As a consultant, I try to reduce my billable hours as much as possible, then charge an appropriate amount for the value I have created, not the time spent, and this leaves me more time for more clients or leisure.
I can't speak to the prevalence of this mentality, but it rings true for my consultancy. The idea of maximizing hours is absurd. We do everything we can to minimize hours, thus maximizing value to the client. That's how we keep our clients happy, and make room for more business.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?