If you have never read the Fred Brooks book "The Mythical Man-Month", I suggest you do see http://en.wikipedia.org/wiki/The_Mythical_Man-Month. There is a summary of his essay "No Silver Bullet" at http://en.wikipedia.org/wiki/No_silver_bullet
At http://www.codeproject.com/Lounge.aspx?msg=3856595#xx3856595xx there is an interesting thread. I will reproduce some of it here as Code Project Loungs discussions can become inacessible.
It starts with an excellent article at: http://www.simple-talk.com/opinion/opinion-pieces/the-framework-myth/
The first response was:
1. Code Reuse doesn't require frameworks. Frameworks are great if you are stamping out the same application again and again. Otherwise, use building blocks.
Frameworks give the illusion to be "easier to use", though, because they attempt to encapsulate the application architecture. This is all good and fine until Change Request #3. With building blocks, the library client still needs to understand the architecture.
2 Don't Repeat Yourself is not an absolutum. When folding multiple implementations into a single method, the implementation complexity grows due to additional cases and error conditions need to be handled. One statistic concluded that having the same code in only two places alone is not a good indicator for refactoring.
3. The best advise about frameworks I heard is this: Before you write a game engine, write at least three different games.
Another response was:
I fully agree. There are no silver bullets which automatically make everything nice and well. And down below I recommended the same approach, I just called them modules and not building blocks.
yet another response was:
Correct. I once worked at a company where some Java "wizards" came in and built a framework to "help" us build our core type of application, moving away from the "building blocks" method.
We went from a shop where we could hire a broad range of skill levels (more junior devs would do the simpler types of setups) and simpler applications would be up in a matter of days to one where every implementation was a six-week slog through the mud, and we could only hire highly-skilled devs who could understand the complexity.
Then nobody could figure out why our costs skyrocketed, and clients weren't willing to pay the extra amount.
Now, to be fair, there were some notions in the framework that were good, and should have been brought in as building blocks. (They may have been, I've long since left). So, not to slag the notions, it was simply the execution of them.
The article is right with the discussion of what they called Harvesting. Build a couple of things, and see what's common.
I think the distillation of the article is something on the order of: unnecessary complexity is bad, and non-optimal simplicity beats optimal complexity almost every time.
I find these arguments compelling and looking at various projects I have been associated and disassociated with over the years, I have to agree that frameworks can be counter-productive.