"They were not built to solve a business need" That's not quite correct. It is perhaps more accurate to say they weren't built to solve your primary business n

"They were not built to solve a business need" That's not quite correct. It is perhaps more accurate to say they weren't built to solve your primary business need. They certainly solve the problem of getting unskilled people to be productive at some level. And this is not a trivial consideration. It takes a great deal of effort, time, and expertise to design a system that maximizes programmer productivity, such that an ideal minimum number of 'programmer-hours' is all that is required to augment and maintain it. And when you do, it is likely that it requires 'wizard level' programmers to put in those hours. Expertise is expensive, hard to find, and presents a certain replacement risk for an employer. The alternative is more dumbed-down systems. The code is less elegant or clever, but easier to understand and imitate. And the 'brutish' nature of such code leads to a certain amount of repetition, which requires more 'programmer-hours' to work on. Hence the need for more developers. As many folks have pointed out, programming today is very much a social activity. The systems themselves are partly responsible for this. There is a need for developers to be 'hot swappable'. And the staffing pressures are partly what are responsible for the popularity of frameworks, for similar reasons. Frameworks are development languages that sit on top of programming languages. In many cases, you barely even need to know the underlying programming language in order to produce fairly sophisticated results. In contrast, to be productive in programming languages, you need to have a fairly deep understanding of your craft and have a good bit of experience in the quirks of that language. Frameworks are like DSLs for a technical domain. While it can take some time to learn the framework language, you can produce more, faster than if you have to build software from scratch (or using just libraries). But what are you producing? As the author says, they are built for "20,000 or 200,000" developers. Not you. And not your problem. They may solve common problems, but they don't necessarily solve your particular problem in the most appropriate way. You may need to rethink your problem to fit what the framework can accommodate. Or face the staffing dilemma.