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.
- Green Chipper -- light forestry and environmental services.
- Info Ark -- a huge collection of useful information.
- Varalaya Farm -- organic produce and sustainable farming education.
- 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 The Smalltalk Report, October 1992.
Object Technology's ENVY/Developer
by Jan Steinman and Barbara Yates
Since the mid 70's, Smalltalk has been the development environment
by which all others are measured. Even before its general
availability, those who had seen Smalltalk agreed that it was the way
development should work. The simple, rapid hypertext like browsing of
code combined with incremental compilation to raise programming
expectations to that of instant gratification.
Like all things too good to be true, the Smalltalk development
environment had a major problem. It garnered a reputation as a toy,
not because it lacked power or expressiveness, but rather because of
the scarcity of large systems written in it. Certainly it was
possible to do big projects in Smalltalk -- Smalltalk itself being a
major example -- but most of the work done in Smalltalk reached a
certain critical mass, then got no bigger. This limit corresponded
roughly to the limit of what one person could manage. The ultimate
individual software development environment was just that: an
A big part of Smalltalk's "instant gratification" is due to the
way it manages change. Each time you save a method, its source code
is recorded in a file, and can be retrieved if necessary. This works
fine for individual developers, but is unmanageable for teams.
At Tektronix Laboratories, we realized that the lack of team
facilities was holding Smalltalk back. Tek wanted to reap the object
oriented benefits of Smalltalk on projects that were larger than one
person, and so developed different team programming environments for
use within the company. These "groupware" environments fell into two
general categories: those that maintained the basic Smalltalk "what
you saved is what you get" philosophy, and those that followed the
C/Unix "check in, check out" philosophy. Beyond this philosophical
split, they all attempted to address a common set of basic groupware
While at Tektronix and as consultants, we've studied and worked on
the groupware problem. Through interviews with users and their
managers, literature research, and personal experience implementing
and using many groupware tools, we came up with a basic set of
requirements for Smalltalk team programming, in roughly the priority
of importance to the users we talked with:
- Integration: groupware must
support the combining of code received from different developers,
which is primarily a function of detecting conflicts and managing
- Code sharing and concurrency
control: a developer must be able to work on a
code module without undue concern over whether other developers
are also modifying the same module.
- Revision history: different
versions of code need to be maintained, so that if new versions
are found to have problems, old ones can be easily retrieved.
- Configuration management:
different combinations of code modules need to be able to be
assembled; previous versions of configurations are necessary for
- Documentation: in addition to
standard Smalltalk method and class comments, the new components
necessary to groupware require documentation support.
- Branching and merging: it is
sometimes necessary to diverge from a single development path, and
when that happens, it is usually necessary after some time to
bring the two paths back together.
Besides these basic needs, a number of specialized needs are often
provided by groupware environments, including performance monitoring
and tuning tools, object storage mechanisms, and facilities for
generating link libraries. We'll examine how Object Technology
International's ENVY/Developer, referred to as simply "Envy", meets
A number of common threads run through the Envy design and make it
apparent that it was designed, and not simply cobbled together.
Envy adheres fairly well to the philosophy that few
concepts, rigorously applied , is better than special cases
for everything. Although it has a complicated user interface, and
does take some learning, most users find it easy to understand and
predictable once they have absorbed the central concepts.
Envy maintains the original "what you saved is what you get"
paradigm, rather than succumbing to the easier to implement "check
in, check out" pattern, and uses the Smalltalk method as the smallest
unit of code sharing. This means that team members can instantly view
each other's work, fostering communication and avoiding needless
Envy is conservatively designed to avoid accidents. It uses
error avoidance , rather than error detection. If an
operation does not make sense in the current state, its menu
selection is disabled. Sometimes this can be frustrating, but we're
convinced it is much better than picking up the pieces after
inadvertently selecting a "you asked for it, you got it" operation.
As a corollary to error avoidance, Envy uses multiple browsers to let
you examine the present state of the system, rather than relying on
multiple reports to tell you what happened to the system after a
Large scale design is fostered by partitioning the
problem into functional units. In fact, the Envy base image
comes pre partitioned into functional units, making it easier to
substitute a completely different user interface, for instance.
Class ownership has been debated in the past in this and other
publications. Envy is subtly different; it insists upon class
definition ownership -- any number of developers can provide
methods that extend a class, but only one developer is allowed to
change a class's structure. Other groupware systems that eschew class
ownership can result in any number of conflicting definitions for a
class, which is deadly to large projects!
Finally, Envy obeys Einstein's dictate that "everything should be
made as simple as possible, but no simpler." Where it makes sense to
override a concept with a special case, Envy does so.
Envy works from these basic concepts:
- all source code resides in a shared repository
- there is a hierarchy of software components that have
container relationships to each other
- loading and unloading a component is atomic
- software components progress through stages, from edition to
version to release
- work in progress is carried out in mutable editions of
- components become immutable by being declared versions
- users are associated with components in specific roles, which
may or may not be enforced
All source code resides in a shared repository, which
accepts changes and makes them shareable immediately.
Instead of the typical sources and changes files, images are
connected to a shared network repository . As soon as a
change to source code is saved, the new code is appended to the
repository. Since all the team members are connected to the same
repository, code changes are immediately accessible to other members
of the team, and they can view or load the new code into their image
as desired. Both the source strings and the compiled bytecodes are
stored in the repository; loading compiled code from the repository
is 5 to 10 times faster than file in.
Hierarchy of Software Components
There is a hierarchy of software components that have
container relationships to each other. These components are methods,
classes, subapplications, applications, and configuration
The smallest component is the method , which is
always a part of a class or class extension. Methods have version
history, as do all other components.
Classes differ from class extensions in
that classes include the class definition and class comment, while
class extensions include only methods. Classes and class extensions
are contained by applications or subapplications. As mentioned
earlier, class extensions provide for multiple owners of bits and
pieces of a class. We use the term "class" to mean either class or
and class extension, unless a distinction is needed.
An application is a collection of classes that
together serve a useful purpose. Applications declare
prerequisites -- other applications they require to be
present in order to function. Loading an application loads its
contained classes and their contained methods.
Applications are actual Smalltalk classes, and as such, they can
implement behavior. For example, when an application is loaded into
an image, it is sent the message loaded . The
developer puts into the loaded method any needed
initializations which should occur when the classes in the
application are loaded, such as initializing pool dictionaries.
Another behavior of applications is that they can respond to some
standard system events, such as image start up and shut down, by
implementing the methods startUp and
shutDown . Objectworks Smalltalk has a similar
function via dependents, but since it is implemented using a
Dictionary , the order of events is non deterministic.
In Envy, system event messages are sent in prerequisite order, so
applications can respond to the events in a predictable sequence.
Subapplications are applications with some
restrictions placed on them. They are always contained in an
application, and are always loaded as part of the application; they
cannot be loaded by themselves. Subapplications have two typical
uses. They are used to isolate platform dependencies, and they are
used to organize classes within a large application. When an
application is loaded, the loading of each subapplication is
controlled by a boolean configuration expression -- that is how a
platform-specific subapplication is loaded appropriately. We use the
term "application" to mean either application or subapplication,
unless stated otherwise.
Configuration maps are named collections of
applications. Most teams will use a configuration map to periodically
rebuild their image, bringing in the latest integrated and tested
versions of all of their applications. Another use of configuration
maps is a "one button" way to load an application and all of its
prerequisites. In a large organization that promotes firm wide
component reuse, configuration maps are used to load all the firm
specific versions of base applications, such as those containing
Object, String, etc. Other configuration maps are centrally managed
to load the latest versions of the firm's reusable components. Each
project team may then have its own configuration map to load its
applications on top of the firm's customized base, plus whatever
reusable components the team needs.
Loading and unloading a component is atomic.
Envy performs "loadbility" tests before beginning the load of a
component, and notifies you of the first error it finds (if any). The
image is never left in an inconsistent state due to loading -- it
either succeeds completely, or fails completely. This is especially
important in big components, subapplications and larger.
A totally foreign concept to Smalltalk users is that of
unloading . Any component that has been loaded can be
unloaded. Until Envy, the way a developer typically "unloaded"
unwanted code was to ditch the image and file in everything except
the "unloaded" code!
Software components progress through stages, from edition to
version to release. Work in progress is carried out in mutable
editions of components. Declaring an edition to be a version disables
changes. A version is released to its containing component.
All components make one or more passes through a change cycle
between "first code" and completion. Any new component is an
edition when it is created. Editions can be changed, and
are signified in the user interface with a timestamp next to the
component name. The developer works on the component until it has
reached a stage that should be "frozen" (especially if it's working,
and the developer wants to make some changes that could break it!).
The developer then makes the component a version .
Versions are identified by a label next to the
component name, instead of the timestamp that denotes editions. Envy
suggests version names, but the developer can specify an arbitrary
string, such as 'for testing 1.0'. Once a component has been
versioned, it and its label are frozen, and cannot be changed.
Therefore, before a component can be versioned, all its parts (and
all their parts, recursively) must have been versioned.
If the developer wishes to make changes to a version, she creates
a new edition of the component. If those changes destroy the
component beyond all recognition, or if the developer simply wants to
do regression testing, the old, unchangeable versions are easily re
At some point, the developer decides it is time to foist her
creation on her peers. If the developer is the owner of the
component, she can release it to its containing
component, at which point, those who load the containing component
get the new part.
To avoid unnecessary interference with the traditional Smalltalk
programming style (as well as interference among team members),
special rules apply to some components' progression through the
- Methods are always editions, and are implicitly released to
their containing class if they are currently loaded.
- Changing a method in a class version automatically creates a
new class edition.
- Classes must be versioned in order to be released to their
containing application or subapplication.
These exceptions allow you to use Envy transparently for at least
95% of what a Smalltalk developer normally does, while keeping your
"work in progress" from being accidentally propagated.
Envy users fill roles with respect to software components,
owners and developers, and flexible access protection may restrict
the roles an individual user may fill.
The creator of any component automatically has the role with the
most authority for the component. This user is called the
owner or manager of the component, and can
reassign this role to another user. The roles exist for one version,
and are carried over into new editions until they are reassigned. We
use the term "owner" to mean either owner or manager, unless
Any number of developers may be assigned to a class.
These developers make changes to the class in their own edition,
which they alone can version. The class owner can then release the
class to its containing application.
Flexible permissions are associated with an application. Unless
the owner of an application explicitly changes it, anyone has
permission to load applications, make new editions of classes, and to
view source code. This default allows development of a class to be a
collaborative effort. If desired, the application owner can restrict
these operations to either herself, or the assigned developers.
Private methods can be controlled separately from public methods,
enforcing the "contract" interfaces between teams.
Owners of applications and configurations are the only persons who
may version them. They also have other responsibilities, such as
determining the prerequisites for an application, or creating new
editions. In the simplest case, there could be one person who owns
all of the classes and manages the application; this is common in
Envy has a variety of browsers for different purposes. Most of the
time the developer will use the Application Manager and one of the
development browsers, the choice of browser depending on their
preferred view of the "world" of their image. Many operations are
available in more than one browser, so the developer is not forced to
switch browsers to perform common tasks.
The development browsers consist of two views of the image world
-- class-centered or application-centered. The Classes
Browser arranges all classes in inheritance order, and has a
second pane that shows which applications define or extend the class.
Italics indicate prototols that are not part of the selected
application or applications. Many list panes throughout Envy allow
multiple selection -- doing this in the protocols pane shows the
union of their lists in the methods pane. Also available is a
Class Browser , for browsing a single class.
The Applications Browser (and the single
application Application Browser ) presents the
alternate, application centered view. Selecting an application shows
a list of all of the classes it defines and extends, plus a toggle
option to show all of the prerequisite classes.
One of us prefers the Classes Browser and the other the
Applications Browser -- it's nice to have the choice. Smalltalk 80
users may find applications somewhat analogous to class categories,
and may therefore prefer the Applications Browser. Smalltalk/V users
are often more at home with the alphabetical/hierarchical view
presented by the Classes Browser.
The Application Manager allows manipulation of
the development stage of applications and classes. This browser lists
all of the applications loaded in the image, with subapplications
indented according to their nesting level. With one application
selected, the other panes list the defined and extended classes, the
application's prerequisites, and the application owner and assigned
developers. This browser is used for organization and management
beyond normal code development, such as loading and unloading
applications or classes, versioning applications and classes,
releasing classes, and determining the composition of applications.
Figure 1: Application Manager details and history of an
Recreating an image in Envy is easy. Using the
Configuration Maps Browser , simply load one or more
configuration maps into the image supplied by OTI. Generally, teams
define configuration maps that list the various applications that
make up their "deliverable". All of the base image applications in
the repository supplied by OTI are already listed in the supplied
configuration map called Envy/Manager. Developers can examine
existing maps in the repository, create new maps, and edit the
contents of map editions. When all of the applications in a
configuration map are versioned and the map is loaded, a
configuration map owner can version it. The map owner does not have
to experiment with the load order of the applications in a map -- the
applications' prerequisites determine the order, and the entire load
A prime feature of Envy is the collection of tools for version
history and comparison. In all the development browsers, it is
possible to open a browser on all the editions of a selected
component. These history browsers list, in reverse chronological
order, all of the editions and versions of the component. From the
editions list it is possible to load a selected edition, or select
any two editions and browse their differences in a Changes
Browser . This browser displays differences by hilighting
lines, and it allows loading the alternate edition if desired.
Figure 2: History of Object, showing differences between two
Sometimes there will be concurrent development of the same
component by two (or more) developers. This happens at the class
level because, unlike "check in, check out" systems, there is no
exclusive locking of a class to prevent others from making changes
they need. This might occur at the application level when a
production version of an application is undergoing maintenance while
other developers are working on "the next release". The same Changes
Browsers which show you the differences between two editions also
allow you to merge two editions by installing one or the other
version of a method or definition, or copying, pasting, and compiling
a new developer-merged edition of a method.
There are two buttons in development browsers worthy of special
mention. The public/private toggle displays public or
private classes (in the classes pane) or public or private methods
(in the methods pane). Private classes are those which should not be
referenced and cannot be subclassed outside of their application.
Subclassing of private classes is strictly enforced; referencing
results in a warning. Private methods should not be called outside of
their inheritance hierarchy. This is advisory, but the application
owner can deny non-group members the ability to read the private
If you don't like the tools provided, keep in mind that Envy is an
open system. Certain low level code that accesses the database is
hidden, not so much because OTI doesn't want you finding out their
secrets (a determined Smalltalker will find ways to view this code),
but because changing these methods could damage the database. Custom
user fields can be associated with any Envy component if
additional state is needed for some reason -- if an organization
needs custom capabilities, adding them to Envy is not much more
difficult than adding them to Smalltalk. An added advantage is the
many reusable classes that can be used royalty-free in your
Table 1 shows how some of the groupware environments we have known
compare in solving the basic needs of the Smalltalk development team,
along with the platforms supported by each. Not all of these systems
are currently available; we listed these that we are familiar with to
contrast different capabilities and to demonstrate the growth in the
"ad hoc" refers to individuals working in separate images, filing
out bits of code. This is, unfortunately, how a lot of team Smalltalk
is still written.
"change set" refers in general to techniques that exploit the
Smalltalk 80 change set mechanism. Tektronix developed browser
support for multiple change sets, and Knowledge Systems Corporation
later refined the concept and marketed change set tools.
"team tools", developed for internal use at Tektronix, combined
change set tools with configuration management, method revision
history, and limited merging. "team tools" used Unix RCS to implement
"check in, check out" concurrency control.
Instantiations enhanced and extended the "team tools" concepts to
produce a product called Application Organizer. Digitalk has since
acquired Instantiations, and the future of former Instantiations'
products is unclear.
AM/ST is a Coopers & Lybrand product that is currently
available for Smalltalk/V only. AM/ST was reviewed in The Smalltalk
Report, March/April 1992.
[951124-JWS: I'm afraid the following tabular information didn't
survive the port to HTML very well. The original used ZapfDingbats,
which is not supported in standard HTML. For now, I've decided to
keep it tab-delimited, so you can import it into a spreadsheet and
change the font for better viewing. If you know of a better way to do
this, please drop me a
Table 1: feature comparison of
various Smalltalk team programming environments.
Who Can Benefit
Not every Smalltalk development team needs a groupware product as
powerful as Envy. In particular, teams of up to three co located
people can get by with ad hoc methods. Corporations with multiple 2 3
person Smalltalk projects can choose to "roll their own," and develop
and maintain groupware based on change sets or other file-outs and
RCS or SCCS. However, these methods break down as the number of team
members climbs above three or multiple teams need to share firm-wide
Envy really shines for managing large projects of up to dozens of
developers. By spreading project responsibility over three distinct
levels (configuration, application-subapplication, and class),
managers can control a large project with precision. Since
subapplications can be nested, project responsibility can be further
divided to an arbitrary level.
Envy has special abilities -- as well as an established track
record -- in developing embedded systems. Anyone who wishes to run
Smalltalk from within anything except a graphical workstation should
consider Envy as their only solution at this time.
Envy eases parallel development with its merging and differencing
capability. Very few projects have the luxury of never needing to
split the development path, perhaps for an important demo, or maybe
due to geographical distance. It is never fun merging the diverged
code, but Envy makes it much easier.
In short, if you have between roughly four and forty Smalltalk
developers on a single project, you can benefit from Envy. The larger
the team, the greater the benefit. As the project leader of a
successful commercial product that used embedded Smalltalk and about
two dozen developers put it, "We could not have done it without
Envy has a solid, industrial strength feel to it. When something
is not as expected, one tends to question oneself, rather than Envy.
It is truly a product without glaring deficiencies; in this case,
"improvement opportunities" is not just a euphemism for
bug fixes! There are, however, some areas in which OTI should
concentrate future development. They are listed in what we believe is
their order of importance.
Multiple libraries: While Envy
nicely satisfies an unprecedented groupware population of up to
several dozen developers working in a single library, it begins to
show stress as that number is pushed above 50 or so, or if the
organization wants a multi-library architecture. The needs of a
corporate wide code repository are fundamentally different from those
of groupware development: ease of finding and browsing functional
units predominate. While Envy has export/import ability between
libraries, it would be an advantage to be able to access at least a
descriptive comment about applications in other libraries prior to
Renaming and deletion: Renaming is
not supported, so one cannot correct mistakes as silly as misspelling
an application name. Neither can one delete a version, such as one
called "OBSOLETE! DO NOT USE!" (However, knowing their mistakes will
continue to embarrass them forever tends to make developers more
careful!) Envy needs a carefully controlled renaming and deletion
User interface: Just as climbing a
hill reveals the mountain behind, UI advances bring out issues that
other, less capable tools have yet to even conceive. Error avoidance
in Envy is wonderful, but with it comes the responsibility of
informing the user about what is happening. New users suffer what we
call the "gray blues" -- wanting desperately to perform some menu
item, and frustrated because the menu item is grayed out (disabled).
Context-sensitive help would be a desirable addition.
The need to support so much functionality combined with the need
to support multiple platforms creates multiple browsers that differ
significantly from the Smalltalk vendor-supplied browsers.
(Smalltalk/V users complain about the "Smalltalk 80-like browsers",
and Smalltalk 80 users complain about the "Smalltalk/V-like
browsers", but they are each complaining about the same browsers!) We
can't offer easy solutions. Perhaps keeping closer to the native
browsers would please people.
Peer review: an important aspect of
successful large projects is peer review. Since browsing others' code
is so easy, we experimented with using Envy for code review (as have
others: see Implementing Peer Code Reviews In Smalltalk
, S. Sridhar, The Smalltalk Report, July/August 1992), by making
annotations in place. It works fairly well with no deliberate
support, so we believe it could be much more useful if more attention
were given this neglected topic. For instance, automatic notification
that a review had taken place, release controls until review
conditions are met, and easy feedback to reviewers.
Documentation: The Envy manual is
accurate and concise, yet it is only a reference manual. Each menu
item in each pane of each browser is described in turn, but there is
no user centered, task based description of the development process
under Envy. Desperately needed are a tutorial and a "cookbook" of
"how do I " questions and answers.
Groupware in Smalltalk has had a long, struggling childhood. The
recent availability of several products designed to foster groupware
ushered in its gangly, clumsy adolescence, with bits missing here and
bugs hiding there. Envy brings Smalltalk groupware into adulthood,
with a complete feature set that fulfills today's groupware needs and
the stability expected of a mature product. Any group of Smalltalkers
working on a common project should consider it a leading candidate
for solving most of their team programming problems.
Jan Steinman and Barbara Yates are Partners in Bytesmiths, a
technical services company specializing in object oriented design,
implementation, and training. Jan has worked with Bytesmiths' clients
to create windowless ("headless") Smalltalk servers using Envy, and
has conducted evaluations of Smalltalk groupware products for
clients. Barbara teaches Envy training classes for Bytesmiths'
clients, and has assisted numerous teams in conversion to Envy. Prior
to forming Bytesmiths, Jan was project leader for the Tektronix
Smalltalk monochrome image and implemented the first 32 bit Smalltalk
virtual machine at Tektronix. Barbara worked on Tektronix's Team
Tools groupware and developed Smalltalk based integrated circuit
testing tools. Together, Jan and Barbara have worked with over 80
Envy users, and an equal number of users of other Smalltalk groupware
24 November 1995, the authors
In the three years since publication of this review, some things
have changed a lot, particularly the marketplace. ENVY/Developer's
competition has fragmented and re-grouped several times, the major
competitor now being ParcPlace-Digitalk's Team/V®, which still
only supports one Smalltalk, using the check-in, check-out metaphor,
which we consider to be inferior.
Other things have changed little, particularly the product. The
ENVY/Developer R1.43 being sold today is nearly as described three
years ago, a long tenure in the dynamic software tools market, and an
eternity in the explosive Smalltalk market.
A new version is available soon, R3.0 (what happened to 2.0? :-).
It finally addresses some of the shortcomings mentioned in this
review, notably multi-repository support. This should ease
Smalltalk's transition from team programming to multi-team
programming, and will greatly aid reuse. Multi-team work is
essentially a searching and browsing activity, which is in many ways
fundamentally different than the activities described in this review.
ParcPlace-Digitalk plans to make Team/V their code management
solotion of choice over the next year or so, but we think
ENVY/Developer will continue to dominate the market over the next
three years, due to customer loyalty and sheer market dominance.
However, OTI can no longer afford to let it go for three years
In Managing Documents, Part
2, we describe (ab)using the storage facilities of ENVY/Developer
to implement a hypertext project documentation system. In
we give some advice on choosing version names. In
we touch on gathering stability metrics from ENVY. In
A Case for Open Development
Environments, we present source code for parsing comments out of
methods and pasting them into ENVY comment fields.