There are no solutions, only tradeoffs.

… But Some Suck Less Than Others

(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.

Post navigation

16 thoughts on “… But Some Suck Less Than Others”

That’s why when someone is happy with his own framework, HE should use it. Published or not, fix it, update it, add new features (and then create a new one because the old one became a monster). Make it useful for you. If you’re not using your own framework, it’s useless for everyone else.

If it works for you, and sucks for others, maybe it’s not perfect, but still… solves your problems.

Nice article. I always enjoy reading Paul’s writing. I don’t think my framework sucks the least (how could I hope to compare to solar?), but it is MY framework and I know it inside and out. It does exactly what I want it to and if I want to change something, I can do it quickly. I honestly think that my framework saves me time and makes updating projects easier, especially for others. One of the best things about my framework, was the learning experience I gained when creating it.

We have tried many of the frameworks out there – and frankly, there are a few good ones. The best ones in our opinion are the “lightweight” ones. These require less of a learning curve, do the dirty work and then get out of your way and let you code. Yet they provide an excellent organized code base structure that is easily maintainable, something that seems to escape too many slap it together PHP code cowboys.

In PHP, CodeIgniter is an example of a simple, but very good framework. In Python, WebPy is a good example, so is the under recognized Werkzeug libraries. Then there is Rails – simply the most flat out productive way to build a decent web app. Too bad it is becoming somewhat of a pain in the .. since they keep changing (oops improving) things like data migrations, etc that seem to require major code changes. It’s not really a bad strategy to build a working first version (aka prototype) in Rails and then if it catches on, do the 2nd version in a better language.

While I agree with most of your points, any programmer that comes to me and wants me to use his framework will be asked one question: “Where is the documentation?”

The biggest PITA of any framework, no matter how well-written, is getting up to speed and becoming productive. If I have to seep through 17 layers of code in order to grok what goes on during a request, then you’ve lost all the goodwill you might have gained in your particular framework implementation.

As an employer/project lead, I also want to know what the state the framework is in if the author should happen to walk out in front of a bus tomorrow morning.

Having your own framework for your own project is great. I’d very much encourage anyone to build several, to explore ideas of programming and interconnecting complex tasks. For any project that has more than just one or two people involved, choosing between rolling your own and going with a “standard” framework becomes much tougher.

You said, “The biggest PITA of any framework, no matter how well-written, is getting up to speed and becoming productive.” That is exactly what I’m getting at when I say above, “Learning someone else’s code is much less rewarding in the short term than writing your own code.” Thank you for helping to illustrate my case. 🙂

“By definition, this means that the framework you write for yourself sucks less than anything else out there — it feels more rewarding. ”

While I agree with this, I find its even more rewarding to _easily_ integrate other frameworks into yours to do the job. I LOVE being able to browse SOLAR and Zend apis for a feature I really dont want to implement. After a quick svn:externals into my lib directory, all that functionality is ready to go, instantly.

Its important that the framework can expose itself at a lower level as “just” a loosely coupled collection of classes. Atop of that, it should add the magic sauce classes that lets you write my-first-crappy-blog application in precisely 8.5, 14.65 or 60.7 lines of code, depending on how much you like the sauce. The issue is that once the magic starts seeping below, you get classes riddled with singletons, “configuration managers” and other nonsense, to the point where you have to pull the whole framework into the application to get anything working.

Im fond of SOLAR and Zend in this regard; Many things they offer may not be applicable to my particular project, but the stuff that is can be easily leveraged.

I agree with all that’s said in this article apart from: “Learning someone else’s code is much less rewarding in the short term than writing your own code.”

The first PHP framework I got to grips with was Symfony, for a project I was working on at the time and it probably took a weekend to be able to start getting some stuff together. One weekend and I was generating models and scaffolding the user screens, hugely rewarding! To write all that code myself would have taken a good while indeed.

Documentation is king though, I have been using the Zend Framework lately and while it is very good and definately has some benefits over Symfony, the documentation is just not quite there yet which makes it a little frustrating at times.