Yet another great blog post! Keep 'em coming!
:-)

Best Regards,
Jimmy
www.jnsk.se/weblog/
###

Great post. Soo true.

I must confess that I'm responsible for a few of those ultra-cool, will-solve-every-use-case-including-world-peace frameworks. But as experience and maturity sets in I've come to pretty much the same conclusion. KISS (Keep It Simple, Stupid).

I do agree with what you are saying for the most part, but like everything else in life, it is not so black and white. Frameworks can be a good thing as long as you follow Angers' KISS principle. I personally call it innovation through laziness.

I've been on projects where we've used your line:

"We're building a generic framework so it will take a little longer to deliver the first project. But then we will be able to reuse all this stuff so we'll save time in the long run."

and it worked. Of course, I've also been on others that have failed, but I don't think that is reason enough to dismiss frameworks completely. You should definitely use caution when thinking about creating a framework, however, don't throw the baby out with the bath water.

Yes yes yes. This is why I have such a distaste for the archtiect role. If you never have to maintain any code then you never really get to learn what is maintainable and what isn't. "Why create one class when you can use 10?"

I generally agree with most of the entry but take issue a bit with your first warning sign. Yes, there are business cases for reusable frameworks, and they are not as difficult to create as you indicate. The trick is to build up your framework naturally over time and only framework-ize real requirements as they are needed e.g. no pie in the sky stuff. Organically grown frameworks are incredibly valuable in that they capture hard-won knowledge from implementation teams. Most often they come about when a team does a couple of one-offs and realizes how much they keep re-inventing stuff. At some point, a smart team will back off and framework-tize the common points. But again, the key is to do this based on real implementation knowledge while tackling real problems.

Shops that don't do this and favor one offs end up reinventing the wheel for all eternity and often have an appalling lack of consistency across the code base.

Mike, Kris,

I agree. Sometimes you manage to pull it off. What I'm trying to say is that these are warning signs: When you here something like this you should pay attention to what's going on. Is there a valid business case behind creating a framework and is the framework build in the right way. Martin Fowler talks about harvested frameworks here: http://martinfowler.com/bliki/HarvestedFramework.html

I've been to places where they've literally spent man-years building massive frameworks. Since they spent this massive amount of money on the framework it was forced on every subsequent project to cash in the investment. Of course, the framework didn't fit these projects and just slowed them down making them even more expensive.

Generic frameworks are the curse of Java. It seems that most Java programmers would rather create a framework than actual functionality. The result is complexity, bloat, and poor performance. Remember the XP tenet YAGNI? Code re-use is vastly overrated and good exmaples are actually very rare.

Libraries, on the other hand, are very useful because they are the opposite of generic.

Several years ago I was working as a senior developer for a dot-com start-up. I will never forget a design meeting in which we were attempting to understand how to apply the architect's design. When he couldn't answer questions on how to actually apply his framework, he through up his hands and declared "Well that's implementation!" and left the room.

Jon, what you're describing is a symptom, not the disease. The problem here isn't frameworks, it's bad design and bad project management, and teams that aren't results oriented.

Given what you've said, you can take frameworks out of the equation altogether and just say "Anytime a new project is contemplated, that's a warning sign. Anytime a developer writes code, that's also a warning sign. Once these activities are undertaken there's a good chance that a boondoggle will result" :-)

The disease here isn't using frameworks - the real disease is developers writing a bunch of code with vague requirements and no well targetted set of features and users. Giant frameworks happen when developers go wild implementing what-if scenarios and not solving real problems. Take frameworks out of the equation, and they'll just do the same thing in one-off code with equally bad results.

It's interesting, you say "Sometimes you manage to pull it off". You make it sound like implementing an in-house framework within a development is some massive undertaken and grand achievement. It's not. I've worked in many environments, and all of them had in-house frameworks of some sort. Most of them were pretty small, effective, and successful. Yes, there were some giant disaster frameworks out there, but they're exception rather than the rule.

The plain fact is that frameworks arise naturally in organizations because smart developers see commonality and factor it out. If they didn't do this they would be reinventing the wheel over and over again, and doing so inconsistently. That leads to more bugs and longer development cycles. If you treat every project as "new" project with use of zero in-house frameworks, that means you're starting from scratch every single time. Perhaps this is good from a consultants point of view, but it's bad majambo for businesses that are investing in software development for the long haul.

"Most of them were pretty small, effective, and successful."

Yes, I like it! That's the type of frameworks that will work!

"smart developers see commonality and factor it out."

That's the best way to build frameworks. Martin Fowler talks about Harvested Frameworks vs Foundation Framework here: http://martinfowler.com/bliki/HarvestedFramework.html

I'm not directly criticising frameworks in general. I'm criticising complicated designs. Small, effective frameworks seems to be the way to go. Unfortunately those are not the most common type of corporate frameworks you find.

So in my copious, free time I'd like to write up in excruciating detail why

"We're building a generic framework so it will take a little longer to deliver the first project. But then we will be able to reuse all this stuff so we'll save time in the long run."

is wrong. The research on this stuff isn't new. I think I'm still just flabbergasted every time someone makes this kind of statement which is not an effective counter-argument.