Sheldon Brahms
Date: July 9, 2001
Modified: N/A

BACKGROUND
The original version of this paper was written to the Open Hyperdocument System developer group in response to an exchange between Doug Engelbart and Grant Bowman on Extreme Programming practices, referring to a piece on O'Reilly.com for background.

THE CASE STUDY

As many new programming and development philosophies begin to take their place in the modern computer world, the manner in which they are adopted can often be much more universal and "cross-cultural" than may be supposed. For example, even in commercial projects, Open Source principles can often be applied to great effect, and Extreme Programming (XP) philosophies can have many beneficial effects on development cycles and project implementation.

To illustrate this, we will describe a Collaborative Newsroom Environment developed for a media conglomerate in 1999-2000. Although it was a commercial product, we used many Open Source Principles during its development. And even though we did not call it Extreme Programming as such, we also adopted many of those philosophies. The result was a project with a dramatically shorter development cycle than was originally estimated, as well as utility and useability that made it an immediate success with the intended end-user community. And not at the least, it provided management one key thing they were looking for, a quick return on investment (ROI).

The project description was for a newspaper editorial and production environment. By nature, it needed to be collaborative, so that was designed in from the beginning. We needed different levels of access privileges, to separate what reporters could do from what editors could do to the various files. The workflow would go from the reporters/writers to the editors, who would do their various editing chores, as well as preliminary page layout and markup. From there, the jobs passed into the production department and onto a different platform for page layout and makeup. All through the process, the environment needed to integrate with the Internet for e-mail and web browsing. It also needed to integrate with a variety of Associated Press file servers for news downloads, photos, stocks and other items, so connectivity was important.

First off, although we had a fairly complex feature set in mind, we followed the 80/20 rule in what we settled on for the initial release. We figured that we could always add later, after the system was already in use and there were productivity gains enjoyed. In other words, we wanted ROI to be quick, and not waste our time on things that would add little of immediate value.

We also followed the release early and often principle. It kept the activity pace a little hectic, but it gave us a useful product almost immediately, without a long development cycle. We would bring new features online as soon as possible, and send out new releases as soon as they were stable, sometimes two a week. Learning curve needed to be shallow and natural, so the features were added in the order that they would be used. It was important that the software be accessed in a fashion that the staff was already used to in order to reduce training time, and therefore, cost of implementation.

The development team was kept extremely small, basically only the programmer and one other person, whose job was to install and test the releases at the newspaper as they were made available. This way, we kept a handle on iterations, and kept the versioning as simple as possible. It also gave us a definite and useful feedback loop to and from the end users.

When we got feedback on the product, we could make use of that immediately, without going through unnecessary layers of programmers for implementation. This allowed for fine tweaking of the way the software operated, particularly with respect to interface and workflow issues. It also enabled us to stay in direct contact with the user community, so that the software could meet their particular needs, and not just be what we thought it should be.

The project was successful enough that it was in use almost immediately, and allowed for a planned system migration to take place painlessly, and even ahead of schedule on the production side. The training time was minimal, and the users had there own particular work abilities enhanced in ways that were very natural to them. We even wound up having quite a number of features that were hidden from the users at the beginning, and enabled gradually as time went on. There was also enough modularity that new features could be added easily whenever necessary at a later date.

It was quite enjoyable to work a project in this way, as it eliminated many "normal" distractions. It kept the work focused and the pace rapid, and created a virtually no downtime process cycle. And perhaps most importantly, it kept the developers and the users on the same page throughout the project. Or as Doug Engelbart might say, the designers and users were "smoothly co-evolving".