Frameworks are all the rage these days. Frameworks for building web sites. Frameworks for building applications. Frameworks for building databases. Frameworks for building frameworks. Okay, I made the last one up but I’m sure that sufficient noodling around the net will reveal at least fifty dozen attempts to do just that. But are frameworks really all they’re cracked up to be?
Let me frame my commentary in the context of a concrete example. I recently had occasion to modify an existing web site to add some additional functionality. The requested functionality was a perfectly logical addition to the existing site, and while not trivial to add, should have been relatively straight forward. It turned out to be far more difficult than it should have been, and, though it was possible, the resulting interface was considerably less than ideal. The precise problem was that I needed to add a data field to one of the objects (I use the term to refer to a logically related collection of data describing a single item, such as a person) which happened to have a “zero to infinity” cardinality. That is, it was optional but there could also be an arbitrary number of instances of the information for a given instance of the parent object. The ideal interface would have been for some sort of ajax-y thing that handled those objects on the same page as the rest of the data for the object but I could not make that happen for various reasons.
The site in question was originally built by someone else using a framework. This framework attempted to be a general purpose system for handling random data entry for arbitrary data structures. It does this using a series of configuration files which describe the database tables. It turns out, however, that this framework has no ability to model the semantic relationships between and within the objects. While this is not necessarily a problematic limitation in general, in this particular case it is.
While the framework used by the original programmer would have been brilliantly useful for a simple data structure with one or more largely independent object types which nothing more than drop down lists for subordinate arbitrary cardinality data, it turns out that it fails miserably at handling arbitrary structures as subordinate data. Being a somewhat competent programmer, I did what any decent programmer with a bit of time would do – I cranked up my mad skillz and set about figuring out how to modify the framework. Several hours later, it became clear that such a modification was not practicable due to various factors including the dreadful state of the code (which I will comment on in another post).
So where did this leave me? It left me with having to use a data entry scheme that did fit into the existing framework, and one which was not ideal. The framework prevented me from using modern ajax techniques to make the interface convenient. Instead, I was relegated to using an interface reminiscent of the previous century. But you might be wondering if this task would have proved any more tractable with a different framework. It might have, but I did not have that option. I had to work within the existing code. I did not have the time budget to redo the entire system.
Had the site been purpose coded for the actual data structures in use and their semantics, there would have been no problem adding a new special set of sub data to one object. I would have had to write some relatively complicated code but it would have been restricted to only those portions of the system that had to deal with the new subordinate data, and that did not even include every place that dealt with the parent object. Even if the purpose built code had not anticipated such a modification, I would still have been able to make it without completely ripping out the guts of the site. Note that this assumes that the purpose built code was not structured as a framework!
I learned something else about the framework used while investigating this particular modification. Even the original programmer had run into limitations of the framework. Not only were there special cases in the configuration files, which is possibly excusable, but there were special cases all over the “library” files of the framework! Even leaving aside the dreadful code mentioned above, a fact that accounted for a very small fraction of the special case stuff, this should have made it abundantly clear to the original programmer that the framework in use could not cope with the specific task at hand. So not only was I battling a framework which did not quite fit the semantics of the site, but I was battling one that had been patched, hacked, and lashed together with bailing wire in order to function at all!
So what does this specific example say about frameworks in general? Nothing, really. What it does is serve as an object lesson. Frameworks do not necessarily always make things easier. This is an important fact to remember when considering a framework for a project. While it may seem, on the surface, to be the solution for all your needs, you need to consider carefully. Does it solve the entire problem or only 90% of it? Is that remaining 10% critical if it doesn’t quite fit into the framework’s notion of how the world works? Think hard about how much work the remaining 10% will be to implement using the framework. Will it be possible? Will it require modifications to the framework itself? Will the time saved on the first 90% more than make up for the time spent on the remaining 10%? In this particular example, the answer to that is a resounding “No!”. The framework did not handle even the original problem specification, and any time saved using the framework was clearly used up and then some by the brutal patching and customization to simply get it to the 90% state, let alone making my later modification suboptimal.
Would a different framework have presented a better solution? Certainly. A framework that supported arbitrary subordinate objects would certainly have helped a lot, and it would have moved the bar for how much was supported trivially by the framework somewhat higher. However, it would not have helped with the semantics of the site, a problem which led to a lot of patching in the original framework and might have done so in another as well.
In short, when considering a framework for a project, do not choose one based on a set of features on a comparison chart. Do not choose one because you are familiar with it. And most certainly do not choose one because your organization has a fetish for it. Instead, consider the specific project at hand and consider which points of the project will benefit from the framework and which ones will suffer. Consider those points brutally objectively. If, after such brutal honest consideration, you still believe the framework to be beneficial, by all means use it, but be wary of any pitfalls. However, if you are not convinced that all aspects of the project will be adequately served by the framework, it is worth reconsidering the idea to use a framework at all. It may prove, paradoxically, that scratch coding takes less time!
So are frameworks a problem or a solution? Yes, they are. Every framework has strengths and weaknesses. Consider a framework the same way you would consider any other technology for building a project. Do the strengths complement your project? Do the weaknesses significantly impair it? Like so many other things, it comes down to the relative costs and benefits of the available options.