"Give a man a fish, he’ll eat for a day.
Teach a man to fish and he’ll eat for life.
Give a man a Fishing Framework and he might starve to death before choosing the most elegant, re-usable way to bait the hook. "

Jeffrey Palermo has a great common sense post on the notion of Frameworks [LINK]. He makes so many great points, many of which I’ve lived through first hand, I can’t resist throwing my 2 cents into the pot…

I spent a large portion of my early career designing and building frameworks. As a developer, business functionality is SOOooo boring to implement. You’re implementing something that’s typically very narrow in what it does and to get it right usually is a very tedious process.

On the other hand, generic code is so much fun. It appeals to the natural human tendency to build tools. Putting something together and trying to imagine every possibility for how it might be used. But if chimps focus too much on choosing the perfect stick for that ant-hill, they’ll never have dinner.

If you think about it, there’s no real "wrong" way to write generic code. It’s just less generic. Business functionality either works or it doesn’t. Very frustrating. Generic code always works but can be improved. This leads to endless tinkering, refactoring and a trend UP the stack in terms of abstract thinking. The more generic, the more abstract the implementation.

So many times as Jeff mentions I’ve seen folks dive into building generic code. I have a theory that the more frameworks there are for a given technology the less useful it actually is to build with. Take .NET for example; Microsoft built their own framework. That’s pretty much all you need and what 90% of the world uses.

Libraries are different. Libraries are off the shelf components that you plug in and out. Typically folks don’t build libraries. They re-use them.

Java on the other hand is riddled with Frameworks. Struts, Spring, Hibernate, Cocoon or you can go the Rails/Ruby, Grails/Groovy route.

Every framework has a learning curve. Developers invest time in learning this crap and become resistant to using another framework. Wait a minute, aren’t frameworks supposed to encourage flexibility? As long as you stick to one.

So which one? Doesn’t matter because if a Framework doesn’t support a specific feature you can always extend it. Extend it? Isn’t that complicated? Won’t I have to dig into the framework and change stuff around? Sure but the framework is just a "lightweight abstraction" which can easily be extended.

Ok, say you pick a framework, then build your app. Bingo you’ve saved time. Now the framework falls out of favour. You’re stuck as your developers can’t or don’t want to maintain it. Fast forward 5 years and you’re kicking off a project to migrate "off the framework". Where’d all that re-use go?

So you see how this fallacy goes. You pick a framework because it’ll save you time. Learning the framework takes time but it’s worth it as the code is generic. The generic code is used only once as your business problem is quite small. If a piece of generic code falls in the woods but no one ever uses it, does it make a generic sound?

Who knows.

Generic code is great and it does save time, effort and maintenance etc. But applications don’t build themselves no matter how big your framework stick is. First let’s focus on the business problem and apply common sense. The generic code will take care of itself.