Please patronize sponsors of this page!
Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
- 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
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.
This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!
Originally published in Th Smalltalk Report, July/August 1997.
Frameworks Are Grown, Not Born
by Jan Steinman
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
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
"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
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.
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
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
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
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
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
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
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.
Go to the previous column in
the series, or the next column in the