Framework Abuse

The Problem

Most IT projects involve frameworks. End users like to talk about frameworks when they discuss new applications. Managers add frameworks to their project plans. Architects design frameworks. Developers build frameworks. Currently many IT projects involve framework development. To an external observer or to someone relatively new to programming frameworks appear as a required ingredient of modern software projects. Is this true? Should projects invariably embark on developing frameworks? What should people be aware of when planning, designing, building, or using frameworks? Many frameworks waste time and money. How do you know that your framework project won’t?

Background

Throughout the last 18 months I worked on several IT projects at large financial services companies. I noticed that almost invariably building new software systems includes the development of one or several frameworks. Examples include (in no particular order) testing framework; application integration framework; common services framework; messaging framework; application architecture framework; connection framework; reference data framework; persistence framework; logging framework; caching framework; authorization framework; portal framework; rules management framework; optimization framework; business process management framework; data management framework; presentation layer framework; and so on. In addition, almost all project stakeholders use the term “framework.”

In fact over 80% of these projects had actually abused frameworks. In other words: the framework did not deliver the promises: increased reuse, faster development, better flexibility. These observations don’t fit with my understanding of frameworks’ purpose, how they begin, who builds them, and how they evolve.

What Are Frameworks?

Frameworks promise (and properly crafted also deliver) design and code reuse. However, reuse has prerequisites.

Crafting reusable code requires generalization. Without several like-systems to generalize from, creating reusable designs and writing reusable code remains wishful thinking [Roberts and Johnson].

Reuse also has costs. It costs 1.5 to 3 times as much to create and support a reusable component as it does to implement a similar component for a single application. Likewise, it takes 2-3 product cycles for the benefits of reuse to become significant [Jacobson].

Symptoms

Unfortunately many projects embarking on framework development do not seem to look at the reuse and cost considerations associated with frameworks. In contrast, several common traits of these projects point out a mismatch between the existing body of work and the current use of the term “framework.” This mismatch causes miscommunication between those who use the term appropriately and those who abuse it (regrettably in growing numbers). The mismatch also has implications on the cost, expectations about, and success of software development projects involving frameworks.

Some of the traits that identify this mismatch follow.

  • Building frameworks without considering reuse Generally people have some idea about some connection between frameworks and reuse. Consequently many frameworks tend to appear in areas that could benefit from reuse. However, few projects actually reused frameworks. Most frequently the framework serves a single application. Sometimes projects even abandon the framework under development and start building a new one.
  • Building frameworks without considering the cost of reusable
    software
    Although not a TLA reuse is a buzzword. Most project managers know that associating their projects with reuse makes them more likely to survive the scrutiny of upper management. Who cares about the ROI? However, the same managers waving the reuse flag do not bring up its cost implications. The promise of cost savings through reuse looks good on proposals. The certitude that the initial costs are going to be 1.5-3 times higher typically triggers an ROI analysis.
  • Building frameworks without concrete applications Many projects include frameworks when no applications to generalize from are available. Even if there are, they’re likely to use different, arcane technologies. The people eager to build frameworks would rather tinker with the newest technologies rather than spend their time harvesting common abstractions from fossils. They end up chasing and struggling with understanding the requirements. They focus on defining and solving the problem rather than generalizing from existing solutions.
  • Building frameworks and the first applications using them concurrently Many people end up building frameworks at the same time with the first applications that use them. This seems to make sense since the same developers are working on both. However, it places framework development on the critical path. The generalization work has not other choice but proceed within the time constraints of the application. In addition, should the team need to cut corners, framework development is the first candidate.
  • Building frameworks and assume that they’re not going to change
    Project plans that include framework building typically show that their development stops before (or in the best case at the same time with) the work on the application for which they’re built completes. This would seem reasonable if the framework is merely a piece of scaffolding necessary to achieve a one-time goal. However, setting aside the issue of putting framework development on the critical path, building frameworks does not end when the last line of version 1.0 is written [Roberts and Johnson]. Like good wine, frameworks need to mature. Actual use in several applications provides the builders with valuable insight into the parts that need to be flexible and the ones that do not, closing the feedback loop. Refactoring around the emerging abstractions is a requirement for the evolutionary process. Neglecting it is likely to yield brittle constructs that developers cannot reused outside the precise context in which they were designed.
  • Building frameworks without the required know-how Sometimes projects are so enamored with frameworks that they embark on building them regardless of whether they have the know-how. “Really smart people working on it” so the effort is in good hands. However, intelligence is not a substitute for experience. As skeleton applications frameworks require experience with the application domain. Developers end up learning about the domain while building the framework. They focus on acquiring the know-how rather than identifying and generalizing the reusable parts.
  • Building frameworks to get buy-in from the business Many projects tend to be tech-driven rather than business driven. Rather than the business users seeking a solution to a business problem, the tech side already has a solution (typically a new technology or a tool) and is looking for problems to solve with it. They talk the business users (who ultimately fund projects) into giving the green light by telling them that they’re building frameworks. The business users don’t really know the hows, whats and whens of frameworks. Consequently they go ahead and give the go-ahead in spite of not knowing what they’re getting. Naturally this works only if the business people don’t know anything about frameworks and, like with the emperor’s new clothes, they chose to sweep their ignorance under the rug.

Do you have additional thoughts or suggestions for solving this problem? Add your own comments below.

Leave a Reply