(N.b.: This is a post I've had in the queue for several months now, and while I still don't feel like it's "finished", it's time to just publish the thing and be done with it.)

Laura Thomson says that all frameworks suck -- and she's right! But maybe not for the reasons you think.

Before we get started, let me give her a big public thank you for her praise of my benchmarking methodology: thanks, Laura. :-)

Also, let me point out that I am the author of a framework, Solar, and so I am as much an example of the behaviors I describe below as anyone else.

I don't mean to put words in her mouth, but I'd prefer to extend Laura's phrasing a bit. I'd argue that "all frameworks from other people suck". (Cf. Rule Number One from my "obsessive-compulsive sociopath" blog post.)

The "other people" part is important here. It sucks to have to learn how someone else wants you to work, and that's a big part of what a framework needs from you: to learn how to use it. Learning someone else's code is much less rewarding in the short term than writing your own code. I think there's a kind of subjective relativistic effect: time spent learning and analyzing drags out, but code-writing time flies by -- even if it's the same amount of objective time spent. Time-drag sucks.

By definition, this means that the framework you write for yourself sucks less than anything else out there -- it feels more rewarding. Jeffrey Palermo points out another factor: the framework author is his own customer, and has to satisfy only himself (or his team) when writing it.

Even if you are a responsible developer, perhaps because you are one, you probably will build your own framework, and pretty early on at that. You would be a fool not to; if you face the same set of problems over and over, eventually you will settle on a preferred series of solutions. If you write the same code over and over again, from scratch, on each project that solves similar problems, then you're probably not getting the "code reuse" thing yet.

That collection of solutions-in-code is your framework. It may be highly formalized or very loose, highly consistent (or not), and so on. But it is a framework.

And I guarantee there will be things you don't like about that first framework -- so you'll write another one. Maybe even a third, as you continuously internalize the problem sets, because there's no substitute for front-line experience (do all the testing you like, but real-world use will be the truest critic of your process).

Finally, after all your work extracting that solution-in-code, you will want to share your wonderful creation with the world, the True Path that is clearly useful if only others are wise enough to recognize it. And to those great unwashed, who do not recognize all your effort and genius, your framework will suck.

This is because there are quirks and workarounds and hacks that you have internalized and accepted and are so familiar with that you no longer pay attention to them, and they don't make sense to other developers. Even working-style similarities among framework developers and adopters will only reduce, not eliminate, framework suckage. There's always something that could have been done differently -- and many prospective adopters will see that as a reason to build an entire new framework, from scratch, to address those points, because (by definition) their own work sucks less.

Sturgeon's law says 90% of everything sucks, and the development world is no different. Almost nothing is perfect for every developer: there's always significant room for valid criticism on any project, and even the best projects are lacking in at least one vital area (and that area is different for each project).

It's all about tradeoffs between what you want to do and what you are willing to put up with in order to do it -- and at no point will you get everything exactly precisely the way you want, either with a framework or without one. There's no silver bullet. This means that you have to put up with suckage no matter what -- some frameworks suck less than others, is all.

(Personally, I think Solar sucks least; but then, I would say that, wouldn't I? ;-)

Read the Reddit discussion about this post here.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving you codebase, all while keeping it running the whole time.