Have you ever heard of "framework fatigue"? This term is meant to describe the creep of hundreds of third-party frameworks into development projects. Ten years ago, there wasn't a whole lot of choice out there for Java, my current language of choice, so the average number of third-party libraries included in a project were 1-5, but today, the average has grown too much.
You've got Spring, Hibernate, JUnit, Struts, Commons, TestNG, Joda, Unitils, DBUnit, iBatis just to name a few in the Java space and each of these have dependencies on other libraries and those have dependencies on others. I could rattle off another list for C#. While I don't think that choice is a bad thing, and while I tend to use 20-30 third-party libraries in a project, I do think that there have been certain side effects of this that have been detrimental to technology. I am going to address what I think is the biggest.
Getting a Job
When did getting a job become more about knowing a specific framework and not being an expert on the Java language? I have seen managers walk over qualified resumes looking for the names of frameworks only to land on someone less qualified who decided to put a particular framework on their resume.
In 2010, Kevin Rose, CEO of Digg.com, said the next time he hires for a project, he is going to hire for talent rather than technology. He said that when he was hiring for a project, he looked for developers working in PHP, but after placing the individuals, he decided to branch out to other technologies and the developers he hired, weren't able to make the transition and dare I use the term, "Think outside the box". A talented developer may know PHP, but can easily ramp up on any other technology, whereas, a developer with merely a toolbox, may not necessarily be able to assimilate other technologies fast enough if at all.
Recruiters and managers are the worst offenders here. These folks are not necessarily technology experts so they try to cultivate a candidate that has the exact blend of frameworks that the target company is using. While this doesn't invariably lead to an unsuccessful hiring decision, it often means that highly qualified candidates with genuine talent might be overlooked.
Let's look at an example that I ran across recently. A manager in Denver had a requirement for a developer with Struts 2, so he excluded any candidate without Struts 2 knowledge. In reality, he could expand his search to include an older version of Struts or just MVC frameworks in general. The principles are the same, the technical details can be learned quickly. A talented candidate can take adapt and move with your enterprise. This is what Rose was trying to get across.
Twenty years ago, having just the knowledge of a language or knowing one object-oriented language, could get you a job doing Java or C++, to name two of the bigger choices. Now, you have to learn and have experience with every framework imaginable just to get your resume to a hiring manager. This is why the tech sector says there are shortages in the development field of highly-qualified labor.
My point is that it is impossible to know all these frameworks and it is also impossible to know some frameworks completely. Spring, for example, is just too large for any one person to hold all the knowledge on it's features. Even if you could learn it all, two or three new versions would be out by that time and you learned the first. The key here is familiarity and talent. A rudimentary understanding of what a framework is used for and a little research, will give you what you need to get the job done.
Here is a little secret that developers have known for years and non-technical people have yet to figure out. It doesn't matter what language a developer knows, they are all similar. A talented developer has an interpreter and compiler in his head and thinks in pseudo-code anyway. Applying that to a language or framework is just a matter of figuring out the syntax...and that is the easy part.