• 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
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• 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

Originally published in The Smalltalk Report, October 1992.

Object Technology's ENVY/Developer

by Jan Steinman and Barbara Yates

The Problem

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 individual environment.

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 needs.

Needs

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 dependencies.
• 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 regression testing.
• 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 these needs.

Envy Philosophy

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 branching.

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 problem.

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 Concepts

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
• components become immutable by being declared versions
• users are associated with components in specific roles, which may or may not be enforced

Shared Repository

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 maps.

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.

Atomic Loads

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!

Component Stages

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 loaded.

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 change cycle:

• 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.

User Roles

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 otherwise stated.

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 many organizations.

Envy Tools

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 Application.

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 is atomic.

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 editions.

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 code.

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 application.

Feature Comparison

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 genre.

"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 note.]

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 reusable components.

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!"

Improvement Opportunities

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 importing them.

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 facility.

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.

Conclusion

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.

Biography

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 environments.

Postscript

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 essentially unchanged!

In Managing Documents, Part 2, we describe (ab)using the storage facilities of ENVY/Developer to implement a hypertext project documentation system. In Managing Modifications, we give some advice on choosing version names. In Exploiting Stability, 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.