The Ten Commandments of Framework Development

One for the geeks here. I build programs using primarily the Java programming language and related tools. Java's a good thing in my opinion, though it's recently been declared as uncool by Paul Graham, one of my favorite writers on software matters (for the uninitiated, yes there are good writers who write about software). However, one of the problems with the Java universe these days is that there's just too much. Too many tools, too many application servers, too many APIs, and way, way too many frameworks.

So what is a framework? A framework, as the name implies, is basically a set of software components that allow you to build other software on top of it. A framework generally adheres to a certain architectural style, and to an extent enforces that architectural style as a matter of principle. Things that could qualify as frameworks range from Microsoft's Foundation Classes (MFC), Enterprise Java Beans (EJB), or the Jakarta Struts framework for Web UIs.

Frameworks are usually a good thing. They promote good practices and lead to code that's more maintainable, scalable, yadda-yadda-yadda. But lately in the Java world there's been an explosion of new frameworks. In my view this is bad for a couple of reasons. One is that frameworks are necessarily a bit complex and large, so there are only so many that you can master. There's probably an argument to be made that the best frameworks will win out in a pseudo-evolutionary process where they are adopted by the most,best developers. Sadly, that doesn't seem to be the case. The frameworks that tend to survive are those that show up early and solve a problem more-or-less, so new frameworks that solve the same problem have to be really, really good to justify the cost of developer training time and more expensive maintenance (i think i could argue convincingly that a framework's worth is measured by the number of applications built on it).

The second problem with too many frameworks is that few of them seem to get the attention they deserve to make subsequent generations better. Though few Java programmers would agree with me, i think that Microsoft actually has an advantage with their .NET framework in this respect because there is only one framework (massive though it may be). This ignores the economics and other arguments regarding open vs. proprietary systems; but i sincerely believe that .NET will win the hearts of application programmers if things stay the way they are.

So anyway, not long ago in a forum on the TheServerSide, i jotted down what i facetiously called the Ten Commandments for Framework Developers. A colleague thought that they were moderately interesting, so i repeat them here with no explication. Keep in mind that these are supposed to be fun; i don't really think they should dictate anyone's decisions. The only reason you need to build a framework is that you want to build a framework.

1. A Framework must solve a real problem.
2. A Framework must solve a significant problem.
3. A Framework must have a consistent architecture.
4. A Framework must make a developer's life easier.
5. A Framework must not make a maintainer's life harder.
6. A Framework must be thoroughly documented.
7. A Framework must not deviate from the programming paradigm of the language for which it's intended.
8. A Framework should be independent of other frameworks.
9. A Framework should be at least slightly novel.
10. A Framework should not mix concerns (e.g., no database code in a UI framework).