As you develop any application, you will need to choose various tools, libraries and frameworks that you want to integrate into the application. In some cases, this could be a very simple task of choosing the most popular and widely respected tool. However, this is not often the case. In most cases, there are several tools that could fit your basic requirement, and they all have their own unique issues. The question then becomes, how do you choose between the various options? I have talked about this concept before, but it was long ago and had a slightly different focus. So, today I give you these new and improved 7 tenets of framework selection.

What are required features?

Before you start any selection process, you need some level of criteria. Assuming we ignore price, you still need to determine if the framework is suitable for your uses. What features do you need that will offset the cost of integration? This should be a minimal requirements list only, otherwise you will always choose the “kitchen sink” framework regardless of whether it fits best. As an example, look at an xml parser library. It should be able to create a DOM and return the list of well-formedness errors. If you use DTDs, you would include DTD validation as a requirement. However, this does not mean that the parser needs to support XSDs, because you do not really need that feature.

Are there any incompatibilities with other tools, frameworks or libraries?

As cool as a framework may look or sound, does it have any incompatibilities with other libraries you are already using? This happens a lot in the JavaScript world when dealing with various components. As an example, you may use Prototype as your JavaScript framework, but when you are looking for embedded HTML editors you need to check if they are compatible with your particular version of Prototype. I had researched this example at a previous job, and one of the editors was eliminated because of “problems” with the version of Prototype we were using. Thankfully, incompatibilities are normally documented and sometimes a newer or planned version may correct the issue.

How extensible and customizable is it?

With any framework that solves more than a small problem, you will need to customize or extend it in some way. This can be done in Java with the use of Interfaces. If we go back to the XML parser problem, I can create a custom error handler class that implements a specific interface and supply it to the parser. This type of customization is fairly straightforward and should be available in most frameworks. The other type of extension is the use of a plugin. A plugin is defined differently for each application, but generally you drop your code into a predefined location. For example, some of the embedded HTML editors allow you to drop in JavaScript code into a directory. This code must meet a specification, just like a Java interface. Plugins are an interesting model because they allow you to create features that are not available in the original framework or application. There is a lot of power in this type of extension and it is highly desirable.

How mature is it?

There was an interesting post on CodingHorror that explained the hot/crazy scale. The hype cycle that you see around new technologies should be applied to the hot/crazy scale to determine whether something is really suitable for use. A good example of this is the difference between Java-based web frameworks and NoSQL products. The web frameworks have been around for years and are very stable. NoSQL is currently a very hot product area. There are a lot of tools that are being built, all with a different set of assumptions and expectations. With any of the tools there can be stability or consistency concerns because you may not be using the tools for the purpose they were designed. This is where the hot/crazy scale is useful, if the application acts too crazy then it does not matter how hot it is.

Can you quickly prototype something to determine ease-of-use?

About two months ago, I wrote about experimenting with new technology. If you are not experimenting with technology, then any time you need to use new tools there will be a significant effort in learning the tool. One thing you can do is prototype a simpler problem, something that can be completed in a day, with all of the tools. You need to put a time restriction because the idea is to determine how easy it is to use the tools. By giving all of the tools the same amount of time, you can get an idea of relative simplicity and productivity within the framework. Prototyping also helps determine if the style of work fits your environment. Even the best tools may require a scripting language that your team does not know, this increasing the implicit cost of using it.

Where can I get help?

Mature frameworks will always have more help available than their newer competitors. Community forums, mailing lists, blogs, and even sites like StackOverflow provide a wealth of information. If there is little activity on forums or mailing lists, definitely review StackOverflow for the number of questions related to the frameworks you are researching. Finding help or example code is extremely important in the process of learning new tools. Looking at blogs is also helpful because it tells you who is talking about the framework. If only a small handful of unknown blogs are talking about it, then the framework could be too new or just not gaining adoption.

Useful bonus features?

Bonus features, meaning features that you do not require but are available in the framework, are always interesting but should not be the main reason you choose one tool over another. There are likely other reasons that you should choose a framework, but if two are fairly similar, the bonus features could be the tie-breaker. Going back to the XML parser example, you only required DTD parsing and validation. If two frameworks have your required capabilities, maybe you choose the one that has XSD validation over one that does not. This could make sense, especially if you think you might use these features in the future. However, do not get too enamored with the breadth of features as it could cause you to choose a framework that is overly complex.

Interestingly, these same tenets could be used to build your own product or framework. Having these targets in mind will help your product gain adoption, much like the current popular frameworks.