This isn't that. My hostile working definition of a framework is something that
. breaks core assumptions about a language or system
. limits what a user is permitted to do
. increases complexities by adding new abstractions
. has non-specific specifications by using unclear and imprecise language
At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions.
Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution.
Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration.
Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable.
Given a product:
. Systems should not continue to function without the programmer
. Code has to constantly be rewritten in order to achieve the same ends
Also it permits the users to go on constant employer funded vacations to conferences and training sessions.
From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following:
. Job security by ensuring brittle applications
. Endless tasks by ensuring endless complexity
. A sense of elitism and entitlement
. No expectations of deliverables
. Be vague enough so blame can get shifted if things break
By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done.
The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible.
In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power.
People adopt the patterns because they want to have the perceived protective properties of the obscurities.
Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic.
...
Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
That reads like a parody to me - the cynical engineer that uses conspirational thinking patterns to create a narrative of the world when emergent outcomes are the causes.
Look for counterexamples where your cause incentives don’t exist yet the same outcomes still do: that is scientific thinking.
> Job security by ensuring brittle applications
> Endless tasks by ensuring endless complexity
> A sense of elitism and entitlement
> No expectations of deliverables
> Be vague enough so blame can get shifted if things break
The last thing many programmers desire is a millstone of old code they are responsible for. Perhaps you posit that they subconsciously desire to make complex code to give them job security? I suggest you watch (or ideally become) a founder engineer, who’s incentives are the opposite of all the above, yet the founder still ends up with the same problems.
All these things are tools and you can wrestle with tools or have them make life easier.
The question is about in what direction this tools assuage the creative process.
I've had the luck of seeing and being involved in codebases to both billion dollar successes and million dollar moneypits.
There's certainly patterns and difference I've seen.
The most notable one is successes seen to use a lot of boring unexciting old software with ugly websites.
Like say emacs, that's got an ugly old site. Or what about GCC? How about the Apache site? It doesn't even hype up how amazing and easy your life is with their simple and elegant efficient masterpiece. What about debian.org? FFTW? PCRE? Sqlite? imagemagick?
Now compare this with react and vue.
One is "we have this tool" and the other makes lofty emotional pleas about your relationship with your work. They're fundamentally different approaches and thus have fundamentally different outcomes.
One accomplishes a goal while the other accomplishes an affectation.
The premise is how to write a successful framework. The cynical takes are presented as advice.
It's structured like those guru business books like "Blue Ocean Strategy" or "Little Bets".
That genre requires an additional separate focus and some further work. It's by a bunch of narcissists who ran multiple businesses into the ground who pivoted to being a guru and offer acronyms, charts, and X-point frameworks in tidy books with a bunch of business examples, most of which catastrophically collapse within 12 months of publication.
And then the books sell 5 million copies, the authors get Ted Talks, it's the same mechanism at play. People pass around their Clayton Christensen of Geoffrey Moore diagrams and crib paragraphs quoting them like they're bible passages. And people eat it up. It's wild.
I remember looking at the Appendix of one of Jim Collins books for the first time about 10 years ago where he talks about his methodology with his team. When you start cross-referencing and see the omissions, mistakes, and misrepresentations, it's wild. I was like "wow this thing is nonsense".
You've got Sutherland's Scrum, Collins BHAGs, and you burn through $20,000,000 in Series A without releasing shit. Alright, I guess that's what we do.
This is a great reply and something I've noticed IME as well. I'm sure there is an economic term for it, but it's like perverse incentives coupled with unconsciousness.
Echoing the other replies that we want to read more of your thoughts (book, articles, blog). Is your site in your profile the best way to follow you?
This is easily the most accurate description of what a frameworks are and the consequences of their adoption I have come across in my 25 years of experience in industry. A not so minor quibble: I think most end users of frameworks approach framework selection with good intentions, likely from a position of naivete, rather than from some sociopathic desire to build a bunker for themselves in their workplace. This of course doesn't change the outcomes.
This isn't that. My hostile working definition of a framework is something that
. breaks core assumptions about a language or system
. limits what a user is permitted to do
. increases complexities by adding new abstractions
. has non-specific specifications by using unclear and imprecise language
At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions.
Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution.
Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration.
Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable.
Given a product:
. Systems should not continue to function without the programmer
. Code has to constantly be rewritten in order to achieve the same ends
Also it permits the users to go on constant employer funded vacations to conferences and training sessions.
From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following:
. Job security by ensuring brittle applications
. Endless tasks by ensuring endless complexity
. A sense of elitism and entitlement
. No expectations of deliverables
. Be vague enough so blame can get shifted if things break
By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done.
The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible.
In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power.
People adopt the patterns because they want to have the perceived protective properties of the obscurities.
Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic.
...
Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.