Andy Grove's Weblog

How Frameworks Are Born

All code stems from the desire to build a solution to a problem. Typically, a developer will start out by writing some simple code as a prototype to solve a portion of the problem and as the prototype evolves and the developer realises that the code is becoming repetitive or verbose, he or she will start to re-factor common routines into a framework.

Simple, repetitive coding tasks are not intellectually stimulating for talented developers and the natural tendency is to innovate and build frameworks to reduce the amount of ‘end user’ code that needs to be written. However, there are some fundamental problems with this approach to software development from a business perspective:

• The proprietary framework does not necessarily reduce the amount of work required to solve a problem and in fact may increase the development time. However, frameworks do introduce a far more flexible solution and this may save development time later in the project.
• The proprietary framework is likely to be complex and difficult to maintain and is typically only understood by one or two developers in the team.
• When the next project comes along, the framework will most likely be modified to add new functionality and this will require the previous projects to be regression tested unless multiple versions of the framework are to be supported.
• Commercial frameworks may well already exist for the problem being solved but it is often not practical to start an evaluation process of third party software and equally there may not be sufficient budget for this course of action. It is also against the developer’s nature to want to buy in a framework rather than develop his or her own.
• Conversely, it would probably be more economical in the long run to license commercial frameworks rather than have development staff effectively acting as an internal infrastructure software house. There is an economy of scale to be achieved by purchasing proven solutions.

A Better Solution?

Code Generation offers another solution to this problem. The purpose of Code Generation is to automatically generate source code for a specific framework based on some high-level meta-data. This meta-data could be a UML model, a relational database schema, a screen design, or something more complex. The key benefit of Code Generation is that the developer’s intellect can be channelled into an activity that is more beneficial to the project and reduces the amount of proprietary code in the resulting application.

Code Generators don’t mind writing repetitive code. Code Generator’s don’t stop and think "Hey! I could re-factor this method!".

However, the real benefit of Code Automation is that if the underlying framework changes substantially (for example going from EJB 1.1 to EJB 2.0) then the code can be re-generated for the new framework. Re-generating the source code is a far simpler task than re-factoring a large code base.