• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• Dharm Atma Yoga -- Kundalini yoga instruction
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• Environmental Education Outreach -- providing environmental education worldwide.
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Green Chipper -- light forestry and environmental services.
• Salt Spring Island Society for Community Education -- community education on our island of 10,000.
• Veggie Van Gogh -- two artists' mobile warehouse and living quarters, petroleum-free!
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel

We've noticed that many "frameworks projects" seem to fail, while successful frameworks in actual use tend to have been developed bit-by-bit by a small number of people, often as a "guerrilla project" outside of normal work.

The large framework projects often develop a life of their own, becoming an end rather than a means, while the developers of the smaller frameworks never lose sight of the fact that the framework is but a means to some other goal.

Much of this is due to human nature and office politics. Organizations tend to build empires, because empires are often the measure of success in an organization. Which people have the offices with the windows? Among them, who has the office with the best view? People measure their personal success in headcount and budget, neither of which is highly correlated with success of result!

Conversely, the "guerrilla framework builder" is seldom rewarded or recognized. Part of this is because guerrilla projects are by definition not part of the job! "I told you to build a widget, but instead you built a widget builder -- why can't you just do what I tell you to do!" Because of such reward systems, guerrilla framework builders are often loath to hawk their own wares -- why call attention to the fact that you were doing something other than what you were supposed to be doing? Many successful guerrila frameworks builders keep their tools to themselves rather than sharing them.

So it is a struggle against these two forces by which successful frameworks become available to a larger audience -- is it any wonder there are so few of them out there?

What is a framework?

The term "framework" is much bandied about these days. A web search on the topic yielded some comical claims. Five years ago, many procedural software development products were enhanced with a subset of object technology, and the boxes were then stamped "New! Improved! Now with objects!" Today, you can substitute "frameworks" (or "Internet") for "objects" and witness the same trend.

For this column, we're defining "frameworks" rather loosely:

A framework is a collaboration of classes structured as a re-usable template that can be parameterized for widely differing end uses.

"A collaboration of classes" rules out class hierarchies that are subclassed for re-use, and "for widely differing end uses" rules out larger systems that are too tightly bound to a particular problem domain.

Although this definition might seem overly broad, it is necessarily so if we are to include the numerous "mini frameworks" that skilled developers constantly create and exploit. Such small frameworks often begin as tools to solve a particular problem, then are generalized to solve entire classes of problems.

"A re-usable template that can be parameterized," should also be interpreted in the broadest sense. Obviously, a word processor can have templates, but is not likely a framework, just as an API can be parameterized, but need not be a framework. The "template" is often an abstract class that is "parameterized" by subclassing, but it could also be a "chameleon object" whose behavior changes depending on how it was initialized.

Simplicity is often the key to generality. The more complicated a framework is, the less general it is likely to be. For example, the Smalltalk, model view controller (MVC) is often regarded as a framework, yet its essential form consists of no additional classes, and just a handful of "global" (implemented in Object) messages.

In MVC, any object can have one or more dependents that it knows absolutely nothing about, except that the dependents are interested in changes to the object. Conversely, any object can be a dependent of any other object. To do useful work, the dependents generally know something about the object they depend upon. The essential messages changed and update: form the core of the whole framework -- the view and controller are, strictly speaking, unnecessary, and are merely a specific parameterization of the dependency template.

How do I make one?

Our experience with big and small, formal and informal framework projects leads us to some rules for successful framework building:

• frameworks evolve; they aren't created on demand,
• a nurturing environment is required,
• before something can be re-used, it has to be used,
• publicity is important to achieve wide re-use.

Frameworks evolve

The first point is crucial; it is the one most often neglected in huge framework projects. The mentality is usually, "Hey, let's build a framework and then make everyone use it," but this "framework by decree" pattern of development has significant problems.

Essentially, the desire to decree frameworks rather than letting them evolve comes from the waterfall development concept that you have to have one thing compeleted before you use it to advance to the next thing. This has several problems:

• How do you know your framework is really filling a need if no one needs it until after it is done?
• What happens if your schedule slips? (What happens if your schedule slips badly ?)
• What if the requirements change?
• What happens if requirements don't change?

We're constantly amazed at the massive projects that are based on assumed needs. "We're having trouble keeping the features of our software from interacting, therefore we need to build an AI framework to manage feature interaction." Some fifty person-years later, they still have interacting features, but we assume they now interact in some artificially intelligent way.

Use by decree always gets frameworks into trouble, because good frameworks are difficult to build. Either their schedule slips, or they become watered down, essentially becoming "too close" to the application to still be considered a framework.

If the schedule slips, and others depend on the nascent framework, then everybody's schedule slips. Even the threat of a framework schedule slip usually results in the framework "becoming the application," thereby losing its generality. When the framework loses the essential feature of parameterization, then there's a lot of explaining to do, since the whole project could have been accomplished much cheaper if a framework hadn't been mandated.

Up to a point, "real" frameworks simply laugh at requirement changes -- simply re-parameterize the framework! But changing requirements kill framework projects that have become de-generalized. Somewhere along the line, some manager thinks "what is an adjustable wrench but a handle for this particular bolt I have to turn" and soon someone works the adjustability out of the wrench, perhaps even welding it to the manager's particular bolt. Now the requirement for the size of the bolt changes!

The obvious counter example is the framework that is engineered at great expense (both in developer time and run time) to allow maximum flexibility for a particular requirement that is thought to be likely to change, and then the requirement never does change. You don't hear about these too often, because they are easily swept under the rug -- the only symptom is a system that is too big and too slow and took too long to develop, which describes most software these days!

Nurturing environment

For frameworks to evolve, they need to be nurtured. Developers should be allowed a certain amount of their time to be spent on speculative re-use development, based on broad guidelines. Focused free time is the birthing ground of frameworks.

Of course, not all developers have the self direction necessary to make use of such time; some developers will abuse it. But the potential up side is enormous -- some developers will do wonderful things with this time, possibly exceeding the value of their normal work assignment.

Discovery sharing mechanisms should be available, both within the group, and between groups. A "brown bag lunch" session works well. These should be held no less than once a month, but by rotating responsibility, it isn't hard to have them once a week, which in our experience is the optimal interval. More formality, such as routed white papers, can also be useful, but the extra formality may reduce serendipitous discoveries, and should only be used after a suitable informal idea gestation period.

Rewards systems should not only encourage framework developers, but should reward framework users as well. The old ethic was to produce lots of code; the new ethic must be to re-use lots of existing code.

Use before re-use

An alternative to pre-ordained, massive framework projects that Smalltalk embodies particularly well is best expressed as a Zen koan: "Nothing is ever completed, therefore everything is always complete."

How do you go about doing this "Zen Smalltalk development?" It's easy -- the moment you think you want to build a framework, you must identify and recruit a potential user of that framework. (In the early stages, at least, that customer may even be you, particularly if your corporate culture forces you into "guerrilla framework development.")

Pick a customer who will work with you and be forgiving of incremental releases as your framework evolves. Pick a target use that isn't mission critical -- save that exposure for when your framework is mature! Work in a "buddy system" with your chosen customer -- because frameworks are so very general, you simply cannot anticipate all the re use potential that a "real" customer might find.

This gives you the nuturing environment you require to work through the unknown issues, and it gives you the initial "use" so you can legitimately claim you are ready for "re-use."

Promoting your framework

Only when you have passed the "use test" are you ready for re-use, and then you need to recruit -- very few things get re-used simply because they are designed to be re-used! This may mean some office politics; it will certainly involve going to meetings and spending some time away from the code.

A good "second project" complements the initial project: it should have a fairly demanding customer, and be on a mission-critical application. Your framework will hopefully save the project, and you'll have all the publicity you need to then recruit even more re-users.

Of course, the picture we've painted here is black-and-white, whereas the "real world" is mostly gray, but the extremes hold the key to the means: the annals of software development is littered with the corpses of huge framework projects gone awry, while most well known successful frameworks evolved over time through close collaboration between the framework designers and their customers.