Don't over-reuse

I’m no big fan of frameworks. This comes from bad experience with a framework drawn out of a specialized project. It had to be used in every project we had to implement whether it was appropriate or not. The argument was something like “it provides features you’d have to implement yourself, so it saves you time”. Usually these features would take about one hour to half a day to implement new — exactly fitting the problem. But we had to take all the clutter and deal with it. This was about six years ago, and as far as I know they still use this exact framework… .

Reuse is a good thing, we all know that, and we all draw our benefits from it. But you can certainly overdo it, not every project fits a specific framework.

Ben had a link to recordings of the last RailsConf (and insisted that I watch them) where Martin Fowler and David Heinemeier Hansson talked about what the essence of Rails really is. It does fit a few particular cases very well, but it doesn’t solve all problems for Web developers. Fowler’s talk is a bit more general on Software development, and DHH’s talk presents new ideas for the upcoming version of Rails, but starts with the philosophy and the goal as well as the non-goals of Rails. Both talks are highly recommended.

The reason I write about it is Bruce Eckel’s articel ‘When Reuse Goes Bad’.

This resulted in classic framework-itis. The contractor was no longer just trying to solve the customer’s problem, they were trying to solve all problems that looked like it. So for that reason alone the project would have required 10x the original time and money.

Read it, it’s a short one. I really felt affected by it.

Before software can be reusable it first has to be usable.
— Ralph Johnson