Leveraging Frameworks...

In The Need for Collaboration and Interoperability, one of the things that was mentioned was that we spend a little too much time reinventing the wheel and that we should be reusing components, such as Mozilla. In the July/August issue of ACM's Queue, Douglas C. Schmidt, Aniruddha Gokhale, and Balachandran Natarajan have submitted a piece entitled, “Leveraging Application Frameworks,” which discusses the advantages of frameworks, some pitfalls of frameworks, and provides some guidelines on deciding on frameworks.

The article begins by highlighting that the software industry needs software that is easily extensible, extremely flexible, portable, reliable, scalable, and affordable, but that these software qualities are very difficult to achieve when software is constantly being reinvented and rediscovered instead of reused, and because software is created monolithically with tightly coupled components instead of modularized. When software is recreated, quality is low and the recreation is expensive, and when software components are not modularized, the reusability, extensibility, and maintenance of the software becomes difficult.

The cure to this problem, the article purports, is to create application frameworks. The goals of frameworks is to separate and decouple the application logic from the implementation and platform logic, and basing this on Patterns. By doing so, new applications can be created with the existing platform logic, amortizing the cost of designing, implementing, and validating over several projects. This cost savings can be further extending by using a commercial off-the-shelf (COTS) framework. It is important to note that a framework is an incomplete software package that is only made complete by an application built using it.

While it does tend to reduce the cost of developing and increase the quality of software, the article also points out that frameworks as hard to ”understand, select, learn, use, debug, and optimize.” Most developers use frameworks today, such as X Windows, MFC, Java and .NET's class libraries, etc. These are but a few examples though, and the article lists many more, including things like IDE's and Mozilla which are not on the same level as the aforementioned components.

The article continues to lists some guidelines. One of the interesting comments that is made in the article is that application developers usually take up to nine months to become productive with a framework, because of the need to learn the framework. While this is a globally known fact, the twist that they give on it is that to recognize the suitability of a framework for a given application can usually only happen after the learning curve begins the flatten, and the article argues that this usually only happens after using the framework for at least two projects. In light of which, the cost of learning the framework can only be beneficial and amortized if used on a few projects, otherwise the cost is far too great.

Debugging frameworks is also a consideration, since developers who do not know the internals of a framework intimately may have a false understanding of the framework, which will lead to bugs that are not easily traceable. While using traditional debugging tools to step through code is not usually helpful, the article suggests an actual framework debugger, and suggests a list of features such a software should have. The most important of these features is that since a framework abstracts out some domain information, the debugger must understand that domain information to properly place the user in the correct context.

Developers are warned, however, that creating a new framework is harder than developing regular software, and the article provides some more specifics on how to succeed, although it does state that there is no replacement for experience and insight. To create a framework, the key is to create some reusable classes that will be extensible for the future needs of users. At first read, this seems similar to regular software development, however, when working with libraries, the goal is to not force developers to change their bindings to your library with most releases. As such, it becomes more important to create these bindings correctly to begin with, and the article indicates that this may take a few iterations to make it perfect.

The article closes by reminding us about Frederick P. Brooks's classic The Mythical Man-Month, and how frameworks are not a silver bullet, stating that frameworks “don't absolve developers from responsibility for solving all complex concurrent and networked software analysis, design, implementation, validation, and optimization problems... Ultimately, there is no substitute for human creativity, experience, discipline, diligence, and judgment.” Frameworks are everywhere, and this article gives you some good framework analysis tools.

Speaking of The Mythical Man Month and frameworks, Joe Winchester wrote a piece entitled “Frameworks - Strongest Support or Weakest Link?” in the June 2004 issue of Java Developer's Journal. In it, he mentions Brooks's “Second System Syndrome”, where developers just go adding features that are not required; Joe Winchester suggests that many frameworks fail for the same reason that software fails, and that is for a global misunderstanding of what the customer's need. It seems that all of Joe Winchester's concerns could be solved if all of the advice in “Leveraging Application Frameworks” were done currently, which is another good reason to read it.