Critical Success Factors Of Object Oriented Frameworks

Over the last decade I was a pretty busy framework user. I used all kinds of technical frameworks for GUIs (e.g. MVC & ApplicationModels), graphical editors (e.g. ObjectDrawing) and persistence (e.g. EXDI, StoreTalk, TopLink). Over the last 2 years I also used a domain framework for derivatives trading, called UniversalFinanceServer. Parallel to using frameworks I was also developing and/or extending them, especially in the area of persistence (mapping objects to relational databases), GUIs (building on top of VisualWorks ApplicationModels) and derivatives trading (extending the UniversalFinanceServer).

While I was very successful with some of my framework-projects (all of my projects used frameworks to some extent) I wasn't with others. Therefore I sat down and heavily thought about the reasons for that. In the end I came up with a small set of CriticalSuccessFactors? for using object-oriented frameworks. I recently held a speech on the topic at STJA (a conference on Smalltalk and Java, held in Erfurt in Germany; http://www-stja.tu-ilmenau.de). Therefore these factors are published in the STJA conference proceedings. Unfortunately these are in german, which does not seem to be the right language for discussion here. Therefore I repeat the essence of the CriticalSuccessFactors here (excuse me for my not-so-perfect english):

Iterative development
Understandability
Quality
Appropriateness

First of all, an object-oriented framework cannot be developed in one go, it has to be developed iteratively. Instead of passively monitoring the typical evolution of your framework (white-box to black-box to toolkit) you should plan, implement and deliver at least three versions of your framework. Because this is the only way to get a framework that satisfies the actual needs of your users without carrying too much unneeded flexibility with it. See EvolvingFrameworks for more details on this.

Understandability is critical because "you cannot use what you cannot understand". Understandability comes from the nature of your framework and its documentation.

The most important thing is simplicity when it comes to the nature of your framework. And the most reliable way to destroy simplicity is adding unneeded flexibility. That's why iterative development is so important. Additionally we should use standards and well known design patterns wherever possible to reuse the know-how that people already have. Last, but not least, we should build our frameworks on a small set of central abstractions and use those consistently. A very nice example is the ToolsAndMaterialsMetaphor.

Secondly, documentation is critical to understandability. If we, as framework developers, want our users to appreciate the features we built into the framework, we need to document them appropriately. On the other hand, if we are investigating off-the-shelf-frameworks for use in our projects, we should take a very close look at their documentation. HowToDocumentFrameworks? is a very good question. I personally like the way it is done in DocumentingFrameworksWithPatterns.

One important precondition to reuse is trust. If our users don't trust us, they won't use our frameworks. Therefore we have to pay attention to quality assurance during framework development. If you managed that users lost trust in yourself you will have a very hard time to gain trust again! Here the question comes up HowToTestFrameworks??

Most important to success is the question of appropriateness. Is the framework appropriate for the task at hand? Can we solve our problems with the resources available to us? Is the framework appropriate for:

Skill-level of the team: Newbies are often overwhelmed by the complexity of frameworks.
Domain: Does the framework answer the questions in our domain, does it solve the problems that arise there?
Application volume: Small to medium sized apps are often crushed to death by the enormous infrastructure of big frameworks.
Usage context: Consider downloading an applet that relies on a framework infrastructure with hundreds of classes.
Business strategy: It only pays to learn the framework if we stick to its domain and implementation technology for a long time.

If we are able to answer those questions positively, we have made great progress towards success.

Additionally to these CriticalSuccessFactors of object-oriented frameworks, I believe that the way frameworks and components complement each other will be of major importance in the future. -- PeterMaier

My CriticalSuccessFactor is that the whole framework, including test cases, must be able to be redeveloped from scratch on the train from Munich to Erfurt. The frameworks I come back to time and again have this quality. You learn more each time, and you learn more about what you can leave out. -- KentBeck

Because you've been to Erfurt, you do have an idea of how long it takes to go from Munich to Erfurt (approximately 5-6 hours). Therefore I wonder if you are serious about "redevelopment" within one train ride. I actually haven't seen many frameworks that are slim enough to have this qualitiy. But I have seen many frameworks that do not have this quality but are still successful (e.g. the VisualWorks Application Framework or HotDraw). Several years ago I believed that frameworks need to be slim (after having a negative experience with a big framework and an unexperienced team). Today I think that it depends on the appropriateness, i.e. experience of the framework users and business strategy. But even if you have very inexperienced users and only a short term commitment to object technology, the frameworks do not need to have this extreme quality.

"So then what do you call the libraries that you use which aren't frameworks? Presumably you use things like GemStone or the VisualWorks GUI library, which do not meet this criteria. -- AlanKnight"

Something I've observed in my experience is that a successful framework isn't just iterative, it's also recursive: it uses, or feeds upon, itself in order to grow and evolve. In other words, The framework is a customer or client of itself in this respect (a "protopattern" Ive been calling a SelfServingSystem). Does this ring true in your experience as well? -- BradAppleton

Have a look at the DogFood page. -- DaveHarris

Hi Dave, I have seen the DogFood page, and I'm very familiar with many of the quoted sources for it (Cusumano & Selby, McCarthy, and others). There is a little more going on here with SelfServingSystem than just the developer using their own stuff. Its not just the developer as user, but also the actual system as user. Its a "tighter" coupling. I'll elaborate on the DogFood page.

Hi Brad,

yes this does reflect my experience too. I consider this recursive pattern of frameworks as essential for the evolution, maintenance and testability of big frameworks. It also helps a lot documenting and teaching a framework. -- PeterMaier

Isn't this just the way that it happens? I just finished writing ArchitecturesAreSelfReinforcingMetaphors and then I saw Brad's SelfServingSystem discussion above. Seems like there is something similar going on, to my mind; especially since I consider a framework to be an application with holes in it.

I attended DesignFest at OOPSLA98. Task: design a framework for developing case work support applications in three hours. I thought it would be fun, albeit insane. I ended up pushing TypeObject and a rule engine because we didn't have reqs for an application to ride on the framework. I wonder what would have happened if we were EvolvingFrameworks or just writing applications with XP. Would we have ended up with a rule system? I find rule-based systems fascinating but I've been warned about them.

-- MichaelFeathers

Re Michael's "especially since I consider a framework to be an application with holes in it." I'd argue that the whole concept of "Application" is responsible for most IT failures. I'd like to see the concept of application disappear. The framework structure that would support this is described in my DoItFramework. -- JimRussell

I've found it critical to have access to all the source of a framework, to be able to follow problems where ever they might lead. Microsoft confirms this requirement by publishing the source to MFC. I also think you need completely functional ready-made examples built on top of the framework that you can incrementally perturb to arrive at something new. Frameworks where you have to spend enormous effort to arrive at your first prototype are not that useful.

Finally, I don't think framework success should be equated to framework popularity. If one person or team can create something useful with a framework, it was a success for them, regardless of how many others chose something else. A good example of this is the user interface of the IUE (http://www.aai.com/AAI/IUE/IUE.html). It uses the Fresco application framework (FrescoFramework) to arrive at a powerful result not necessarily attainable by other means. But the number of programmers involved with Fresco is few, and popular it is not. But does that imply failure? -- ScottJohnston

Suppose for a moment that a framework sucked. Then suppose it's merchandized by a huge imperial company. (I'm sure some frameworks, not already mentioned on this page, come to mind.)

The critical mass of the framework, and the huge weight of its parent company, would ensure that everyone used it. These forces would ensure that many entry-level programmers use the framework thinking it's the only one.

This would force the framework authors to then use excessive documentation and excessive internal effort to maintain and upgrade the framework. And they themselves would feel the burden of this framework's technical errors.

Just a thought. -- PhilipCraigPlumlee

My experience has been that the critical factor is flexibility. If a particular application does not need a piece of the framework, it doesn't have to include it. However, as the pieces get put together, they tend to feed off each other and become more powerful. Framework pieces are always fronted by an interface.

Also, we've had good success making sure that frameworks don't interfere with the business logic of the application. Frameworks need to handle common services, like configuration, logging, data access, and initialization. Our framework places no restraints on how the application itself is coded, but the framework allows a working, minimal application to be brought into being in an afternoon with all of the basic services. This helps you to ReleaseEarlyAndOften?.

Good framework pieces also reduce BoilerPlate code. For instance, each JDBC query requires a set of BoilerPlate ExceptionHandling and ConnectionManagement?. Placing those pieces in an independent framework allows each DAO to only deal with the code that is unique to it, and makes sure that common coding errors aren't replicated over and over. The ExceptionHandling and ConnectionManagement? is handled in one place only.

-- AveryRegier

'Understandability is critical because "you cannot use what you cannot understand".' I disagree with this, I have no idea what my brain/mind/imagination actually are or how they work, but I'd argue that I make pretty effective use of them.

OTOH, you do not know if are really using your brain/mind/imagination effectively or just 0.0001%. The point was about not leaving it to the developers to puzzle out a framework and use it appropriately, when they may not have the time or the skill level. Interesting point nevertheless.

-- NAlex

Although I might state that there are two levels of understanding. The first is enough to use a framework; the second is to really understand the internals of it. I do not understand how VTK computes steam traces, but I definitely can use them in an analysis of a hydraulic flow.

-- sean.rioki.farrell

CategorySuccess CategoryFramework CategoryOopDiscomfort