Concluding Thoughts About QPW


Many other patterns came out of our understanding of the QPW project. The project got a start even while the compiler was not finished; this is an example of GetOnWithIt. NamedStableBases reflects the daily builds the project did to incrementally add functionality. They had WorkFlowsInward, particularly during testing: information came in from beta users through the Help Desk to the development team. The team was strongly supported by management and other support functions during the earlier periods as well. We find SacrificeOnePerson in many instances, the most graphic of which is Philippe Kahn's interactions with the press and market; he also acted as a FireWall and PatronRole in this capacity.

This was a SelfSelectingTeam with strong UnityOfPurpose. It operated much as a SkunkWorks: small and isolated, though strategically its focus was much shorter term.

The team had a very low "truck number" (see ModerateTruckNumber), however, because of the high specialization. But there was very strong commitment to the project and good communications that suggest that there may have been more cross-fertilization than we could see. While architects (and other roles) maintained their specialization, they also maintained an uncharacteristically high level of communication among themselves. This balance is rare in organizations and we have found it only in the strongest, "hyperproductive" organizations. We originally captured this structure in a pattern called BuffaloMountain [BibRef-Coplien1995] that was later split into ResponsibilitiesEngage and HallwayChatter. Communication was the glue that held this organization together.

Can we capture the architecture of the Borland development organization and process, and expect phenomenal results if we apply it to large development projects such as we have at AT&T? Probably not. However, its staggering productivity offers a target to shoot for, and some aspects of its management policies and process guidelines may serve small- to medium-sized developments well. To the extent large jobs can be partitioned into small ones, the Borland approach may be suitable for individual parts of large developments.

Borland develops products for a domain and market which, today, has little overlap with the traditional telecommunications market. As large software development organizations move into new markets--such as software development environment platforms and soft human interfaces — the techniques used at Borland will become increasingly difficult to dismiss out-of-hand as irrelevant for large system development.

The software industry has long embraced rationales that dismiss the productivity of stereotypical "Silicon Valley" cultures. We tended to think of PC development efforts of that era as small and simple. We say they have limited markets and don't need to evolve. Borland defies these stereotypes. The QPW product needed to move into a market supported by Windows, Windows/NT, Pink, and conjecturally others including Macintosh — and maybe even UNIX. It will need to interface to a host of different windowing systems and hardware technologies. It is not small, even by AT&T standards (it was larger than the first release of the flagship AT&T local switching product). Borland was able to coax 1 million lines of production code from about eight people in 31 months. Perhaps a PC-based development environment and PC-based deployment platform make developers more effective, and perhaps QPW doesn't have the same fault-tolerance requirements one finds in large telecommunications systems. But those considerations alone don't seem to account for figures that are orders of magnitude above industry norms.

Software maintenance is of critical important to today's large, complex software developments. One suspects that the same will be true for QPW as it offers new features, runs on new platforms, and adapts itself to new operating systems and windowing environments in the market place. One might guess that foreseeing such evolution is one reason for Borland to have chosen object-oriented development techniques and C++ as the basis for their development.

The Borland process operates at an extreme point in our continuum of development organizations. Having a set of extreme data points can be of use to us in our process research, as it helps bound the models we make. We hope the Borland model will provide data that will help us calibrate our process models, and help us better correlate properties of other models we study.

A great big thanks to Carol Johnson at Borland for taking care of most of the local arrangements. I'm indebted to Ruby Chu at AT&T for chasing down QPW product reviews. A special thanks to Doug McIlroy and Peter Weinberger for their critical comments.