The Story of the Version Editor

My favorite project during my career at Bell Labs is a tool called the Version Editor, or just ve. This tool integrates the editing of a source file with the tracking of the change history of the file. The original prototype for the concept proposed several approaches to source change management as well as the editing activity. When I joined the project in 1986, the goal was to move from a concept prototype to a working tool for the programmers in the 5ESS® Switch development organization at Lucent (which was then AT&T). This target organization numbered over five thousand developers working on tens of millions of lines of code that comprised a large telephone switching system. The project used a proprietary version control system called ECMS, which is somewhat similar to the Sablime® Configuration Mangement System marketed by Lucent.

After I joined the project, I rewrote the original prototype for use in the production environment. The tool evolved as we saw what worked and what did not work for the initial users. Eventually, ve came into wide use throughout the 5ESS® project, and a study ten years later estimated the savings attributable to ve use at nearly $300 million.

In 1998, I wrote the paper Version Sensitive Editing: Change History as a Programming Tool about ve and presented it at the Conference on Software Configuration Management.

What ve does

Having this version information available while editing affords the following opportunities:

• Easy to know the author, reason, and creation time of a particular line.
• Lines that were deleted may be examined or recreated.
• Visual attributes can draw attention to lines of interesting heritage.
• Easy to visually distinguish the changes of the current editing session.
• Automatically provide the source level versioning used by ECMS.

In short, activities involving the use of the version control system are integrated into the editor. This means that the version information is at the developer's fingertips during an editing session.

Using version information to find a code bug

This example is taken from my paper and illustrates the value of having version information effortlessly available during editing.

Suppose you have the following snippet of code, as shown in the vi editor:

This is the scenario for this problem: the code snippet is part of a large program that processes many files. It had been working properly, but recently began failing on the opening of some files. Some debugging has shown that the file open is failing because there are too many open files. An examination of the code in the plain view above does not immediately reveal anything. It looks like everything is being done properly. The extra piece of information that does not show in this view is that the bug appeared recently. This means that this code had been working and is now apparently broken. If we have access to the old version, we could compare to see what had changed, that is, what is different in the versions.

This is exactly the type of activity/information that ve integrates into the editor interface. When we look at the same code in ve, we can make ve use visual attributes to draw attention to "interesting" lines: the recently added lines are in bold, and the recently deleted lines are visible and underlined. We get the following view:

Now the problem is much easier to identify. We can see that the break from the loop was changed to a return from the function. This may have seemed like a more efficient bit of code - avoiding an explicit variable to hold the result, but it unfortunately has the effect of not closing the directory file, thus causing the problem behavior. (Of course, ideal design of classes, exception handling, etc., would have avoided this problem in the first place, but this example is extrapolated from real life down and dirty code.)

The point is that having the version information so easily available adds another dimension to the plain text, thus allowing us to know more about what we are looking at and changing. It is likely that the version control system provides tools for comparing versions or even looking up the origin of a line, but most developers will not want to shift context from editing to use another tool set and/or take the time to learn how the other tools work. By providing the functionality as extended features of the editor, the learning curve is minimized, and the ease of use is maximized.

Ve and technology transfer

Deploying the Version Editor was an interesting exercise in technology transfer. A lot of politics were involved in even selling the idea in the first place. The managers of the version control system feared that the tool would corrupt the version history, and this led to early versions being implemented as browsers only rather than editors.

However, it turned out that the real secret to the tool's success was to evangelize the tool among some friendly, adventurous users, and to make it easily available to them. At the time, Bell Labs had introduced a sort of underground mechanism for distributing experimental tools (exptools), and this proved to be the perfect way to distribute the tool, but be able to update it easily and frequently. Some of the important lessons we learned were:

• Find a distribution mechanism that allows frequent and easy updates - persistent old versions of an evolving tool are a sure way to kill it.
• Respond to early user feedback as quickly as possible - fast, personalized responses build loyalty and enthusiasm among the early users.
• A core of early adopters will spread the word and do most of the work to build the tool's following.
• In the case of this tool, it was very important to faithfully emulate the vi and emacs interfaces. Editor interfaces are an important personal issue, and trying to design a "better" editor interface would clearly have killed the project.
• Use of the tool should be optional. That is, users should be able to evolve into use of the new tool, and always be able to do things the "old" way if they choose.
• Related to the previous point, an important implementation issue for ve was that it was completely compatible with the existing version control system. That is, it worked with the system and did not require any conversion of the system or modifications to the system. This allowed the optional introduction of the tool without any special installation date from which a back out might be required.

Transferring the technology from the research organization to production use required almost as much effort as the original tool development. Simply expecting the target organization to pick up the tool after it was "thrown over the wall" by the researchers would have resulted in an early and quiet death to the idea. Rather, the tool had to be aggressively marketed and championed to the end users so that their tool maintainers could eventually be convinced to officially own and distribute the tool.

Saving money

It always seemed obvious to me that the effort in developing ve was well worth it. Maybe I'm a historian at heart, but easy access to version information just seems like something you almost always want to have. And ve's feature of automatically handling the source level versioning of the propriety version control system was a clear time and confusion saver. However, it turned out that this was not so obvious to managers, and early in ve's life, the plug was almost pulled because we could not give a convincing cost-benefit analysis. Sure, we could give anecdotes detailing cases where ve saved a developer a lot of time, but demonstrating that the tool provided actual dollar benefits exceeding its cost was hard to quantify.

When Bell Labs dissolved the exploratory department from which ve originally sprang, I was fortunately able to get into the tools support organization and push ve from there. Use of the tool spread and it became a standard tool packaged with the version control system.

Ironically, ten years after the initial deployment, we used ve for a case study of a research project about tool effectiveness. By this time I had moved to the Software Engineering Research Department, which had been created several years after the demise of the department in which ve was conceived and developed. The 5ESS® project was a rich source of real world data and a good place to research tool effectiveness. By a lucky coincidence, ve leaves a characteristic signature for a certain type of use, and we could track this use against cases where ve was not used and thus be able to analyze ve's effect. The data sample was extremely large - ten years of change history by thousands of developers. The conclusion of this research was that the use of the tool resulted in a 36% productivity increase. A natural question to ask was whether this increase had any real value. That is, if productivity increases by 36% for a task that some developers do for two hours out of a year, the savings are not of any significant value. As it turns out, there was enough data to make a rough estimate of the actual total developer time saved, and associate a standard cost. The end result is that we estimated a savings of approximately $270 million dollars over the ten year period (and that was in 1999, so there have been significant savings since then).