The Dilemma of The Framework Creator
The Dilemma of The Framework Creator
Join the DZone community and get the full member experience.Join For Free
Discover how you can get APIs and microservices to work at true enterprise scale.
Developing or contributing to a framework used by a majority of the software community is one of the prime sources of career satisfaction for a whole lot of software developers, designers and architects. A great framework can be an object of beauty to them, just as a fine cathedral is for its architects – an ex-pression of their creativity.
But a framework can be sustainable and useful only if it is designed with certain principles. This post is an attempt to find what it takes to make a sustainable and widely accepted software framework.
The foundation and vision of the framework
The framework, infrastructure product, library or whatever term is used, should be founded on real-world business needs or requirements rather than aiming to be a general Swiss-army knife. The history of software is replete with examples which started with lofty ambitions and could not stand the test of time because they became over-complicated. Or those that started with a strong foundation but lost the plot somewhere in the quest for being futuristic.
Before trying to unleash creativity in the building of a framework, the framework creator must have a sound backing of the proposed framework’s needs for at least 2 projects, and it would be even better if it is so across diverse business domains. The framework should be used, during its development, to build a sample business scenario as a reference case. It should be able to prove substantial savings in cost of solution building with use of the framework. For example, the Oracle Application Framework was the internal framework on which all the applications of the Oracle e-Business suite are developed and was used in parallel with its own development with the backdrop of some of the e-Business suite applications. Later on, it was exposed as a framework for the external software community as well.
Framework creators tend to have engineering inclinations and having a back-drop of business use cases is important to keep them well grounded, even if it may mean hampering their creativity in some ways.
In this context, an excellent article has been written by Kevlin Henney – ‘Simplicity before Generality, Use before Reuse’ which has been published in the book ‘97 Things Every Software Architect Should Know’.
The importance of convention over configuration
Of paramount importance is the design of the API that would be exposed. It should offer a simple interface for the developers to adopt it. It should not make the developer’s life complicated with a steep learning curve, offering an overwhelming myriad of options or an unwieldy set of interfaces with long parameter lists. Today’s software community is well-informed and has a plethora of options at its disposal. The community does not mind junking standard specifications in favor of simpler and value-for-investment frameworks. This explains the popularity of Ruby-on-Rails or Spring vis-a-vis the standard J2EE1.3 or 1.4 specification, which also served as a wakeup call that resulted in much more developer friendly JavaEE 5 and 6. Convention over configuration is the paradigm followed by most modern frameworks today.
Adoption of spiral development methodology is perhaps best suited for the development of reusable frameworks and a leaf could be borrowed from agile to release often enough for early feedback.
The balance between generality and performance
In building a generic framework, one often trades-off performance. For example, usage of XML for interoperability considerations, usage of reflection, enforcing locking of resources that may be used by only a single client in a particular scenario and so on.
To balance this, the framework creation teams do the following-
• Intelligently modularize the framework or product, providing the users to choose which features they want. Likewise, there should be an option to turn off features and functionality which are not required to reduce the footprint of the framework.
• Clearly define the scenarios where the framework would be the best fit. Provide adequate samples and reference architectures for the usage of the framework.
• Develop optimizations for some specific scenarios and with certain products while remaining stan-dard enough for other scenarios. This however should be done with some care and restraint so as to not provide too many versions and configurations to baffle the developers.
Catering to diverse user competence
Over the years, the software community has grown by leaps and bounds and software development is not the sole privilege of highly qualified engineers. In trying to cater to a wide audience with varying competence, the framework creators face a dilemma – should they assume that users of the framework would like to be spoon-fed or that they would be highly experienced architects and developers who would resent the invasion of their freedom.
Highly experienced architects for example may feel greatly constrained by the restrictions imposed by EJB containers in preventing creation of threads or writing to files and so on. They would welcome less domi-nating and non-intrusive light weight frameworks like Spring which allow more control.
At the other end, there is a large percentage of the community who would like to be spared of extreme granularity and would require facilities to make their mundane development work a drag-and-drop job. There is also the consideration that the framework may be used in totally unintentional ways due to too much of freedom.
It is often difficult to maintain this balance. In today’s ecosystem thus we have a plethora of frameworks with varied degrees of flexibility and simplicity that coexist with healthy competition.
The right supplementary tools and processes
There is nothing like a nice Rapid Application Development Tool to increase adoption of a framework. Yet, often this is the last consideration in the initial versions of the framework development. Be that as it may, the sooner the framework development team realize the importance of supplementary tools and features and incorporate the same, the more traction their framework would obtain. There have been countless examples of efficient frameworks that have not gained as much adoption as their less efficient counterparts which provided the right supplementary tools. What are the right supplementary tools that the software community looks for in frameworks? These could include
- Rapid Application Development (RAD) or IDE tools which could be plug-ins to favorite IDEs such as Eclipse or Netbeans. These may range from basic syntax highlighting to drag-and-drop from palettes.
- Monitoring tools or at least exposure of the right parameters for monitoring like JMX.
- Last but definitely not the least, a thriving support for the framework and succinct user and developer guides.
The above in a nutshell are the factors that every framework creator would do well to consider as a reality check during development of framework or platforms, to ensure a thriving framework rather than wringing their hands in despair after making a beautiful framework that few seem prepared to use.
Opinions expressed by DZone contributors are their own.