The Framework Myth

"They were not built to solve a business need"

That's not quite correct. It is perhaps more accurate to say they weren't built to solve your primary business need. They certainly solve the problem of getting unskilled people to be productive at some level. And this is not a trivial consideration. It takes a great deal of effort, time, and expertise to design a system that maximizes programmer productivity, such that an ideal minimum number of 'programmer-hours' is all that is required to augment and maintain it. And when you do, it is likely that it requires 'wizard level' programmers to put in those hours. Expertise is expensive, hard to find, and presents a certain replacement risk for an employer.

The alternative is more dumbed-down systems. The code is less elegant or clever, but easier to understand and imitate. And the 'brutish' nature of such code leads to a certain amount of repetition, which requires more 'programmer-hours' to work on. Hence the need for more developers. As many folks have pointed out, programming today is very much a social activity. The systems themselves are partly responsible for this. There is a need for developers to be 'hot swappable'.

And the staffing pressures are partly what are responsible for the popularity of frameworks, for similar reasons. Frameworks are development languages that sit on top of programming languages. In many cases, you barely even need to know the underlying programming language in order to produce fairly sophisticated results. In contrast, to be productive in programming languages, you need to have a fairly deep understanding of your craft and have a good bit of experience in the quirks of that language.

Frameworks are like DSLs for a technical domain. While it can take some time to learn the framework language, you can produce more, faster than if you have to build software from scratch (or using just libraries). But what are you producing? As the author says, they are built for "20,000 or 200,000" developers. Not you. And not your problem. They may solve common problems, but they don't necessarily solve your particular problem in the most appropriate way. You may need to rethink your problem to fit what the framework can accommodate. Or face the staffing dilemma.

The problem with companies building frameworks boils down to one simple fact. If a company is unable to differentiate and disentangle it's goals from the goals of building and maintaining a generalize and useful framework.

Companies can build frameworks around solid principles and know when to let them go and develop into community projects. Rails certainly developed in that manner. Likewise, Sproutcore developed for a while under Apple's care, but has also split off, as Apple's goals diverged with sproutcore's.

If you are going to build a project for developers, make sure you have the developer's goals in mind, and not your own. Same is true of building an API.

Nice article. I agree 95% (I always give myself 5% in case I change my mind later about a few things ;)

I once got hired in a company where I found that a developer had convinced the management of letting him build a framework. Since our boss swore by this guy, we had no choice but to keep using his pile of garbage. I've subsequently used various frameworks and have had various frustrations that with time I think I can pin point. Here's my list of recommendations for people undertaking the next life changing framework out there:

- Always start by asking yourself "Am I nearly as good as I think I am?"

- don't try to fix the world with your framework. Stick to the 80/20 rule. Simple tools that solve 80% of problems efficiently and unambiguously. Leave it at that. Please, pleeeaaase don't venture in the other 20

- provide damn good APIs and hooks to extend your base libraries.

- make it equally easy to avoid using your libraries. If your library is meant to be used by somewhat smart and responsible people, do your very best to keep them in charge. You may recommend against certain practices, but don't you put safeguards that prevent me from implementing the occasional hack.

- document both, how to do it your way and how to go around.

- document your framework's capability as well as limitations. I have no clue why most library authors avoid talking about limitations. They know what they are and they know people will ask about them, yet they don't document them. If your ORM lib doesn't offer a certain facility, please just tell me. Spare me the countless fruitless hours of searching google and irc. Let me know I need to go down to sql, I won't mind. Don't just hope that I will never need to use it in my life and leave me hanging. Tell me. TELL ME.

There's a HUGE difference between the .NET framework, that is more a Library of classes, and for example the PHP Cake framework, that really takes all control flow out of the hands of the developer.

In other words, I'm still so old school that I prefer a good library of classes, functions and tools, than the newest I-will-write-all-code-for-you framework.

In the same way, I feel better if I write a library that can be used by any project for a very specific feature (like localization, or disk cache, or something similar) than if I write a framework where everything should be done in the framework way and most logic should be rewritten.