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?
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.
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.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
Is this not the typical mentality?
However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.
I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.
If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.
All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).
I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.
I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.
I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.
Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.