Formalized Sharing Processes: Taming Large Software Projects (1992-1997)

Managing large software projects and maintaining predictable schedules is hard [5]. Project management techniques used for, say, building bridges do not work for building software. A particularly challenging aspect of software projects is communication and coordination among team members. I’m interested in the research question whether and how computer systems can support communication and coordination in this context.

Two extremes of software project team structures that try to address communication and coordination of team members is the chief programmer team [2] and the egoless programming approach [23]. The chief programmer team maintains strictly hierarchical communication patterns where the chief programmer makes all design and implementation decisions. The advantage of this structure is that software project schedules are more predictable primarily because of its limited communication overhead among team members. Egoless programming involves all team members equally in design and implementation decision. The advantage is that faults in the design and implementation tend to be caught earlier than in chief programmer teams and that the resulting solutions are of higher quality. The disadvantage of egoless programming is that communication overhead among team members is much higher than in chief programmer teams which makes project schedules less predictable. This apparent trade-off between predictability of software project schedules and software quality provokes the research question of whether there are ways to introduce formal communication in egoless programming teams and leverage computer systems to reduce the overall communication overhead without imposing the disadvantages of hierarchical communication patterns.

Winograd and Flores [25] proposed to embed organizational activity into formalized conversations and provided a “Conversations for Action” model in form of a deterministic finite automaton in which the alphabet consists of speech acts between two parties, such as “request”, “promise”, “reject” [24], and states represents sets of expectations. I used this approach to model conversations in a typical software engineering environment. The result I called “Sharing Processes” [8] which are not only capturing the usual states of source code sharing, but also track associated requests, promises, rejections, withdrawals, etc. Today most industry software development environments integrate bug tracking systems with their source code management. In these integrated systems bugs are managed following state/transition diagrams similar to the ones proposed in sharing processes.

The above sharing processes were always initiated by a person. In a related project I studied an example of sharing processes that are initiated by the compute environment. The example is a help system for command lines in unix shells that actively solicits help information from expert users (i.e. start a “sharing process”) who introduce new command lines. This active solicitation of information is important because in a typical networked compute environment – as opposed to, say, a shop floor – people do not see what tools are being used, and often do not know who to ask or even what to ask for. I developed a system called ToolBox [11] that identifies tool experts, solicits information from these experts, and presents help information organized by a taxonomy of tools that itself was freely modifiable by users. ToolBox enjoyed some user acceptance within a computer science department in spite of a very naïve expert identification strategy and in spite of user interface shortcomings. It also showed that people were able to quickly converge on a common taxonomy but that with increasing size maintaining this taxonomy became challenging.

A common form of strike is to “work to rule”. The overly rigid enforcement of formal processes usually causes significant damage to productivity. In the context of workflow systems I studied architectures that allow for in-flight changes to formalized processes in the form of specialized Petrinets called “information control networks” (ICN). This work resulted in Chautauqua [4] using an architecture centered around an active object server. Various functional units of Chautauqua, e.g. clients, process editors, token scheduler, and other clients register standing queries with the active object server. The scope of these queries is not the entire object base but only the part that is affected by an update. This mechanism enables both the propagation of tokens (i.e. the representation of the state of a work case) through the ICNs as well as the management of ICN changes and tokens affected by changes. Tokens can be sent to individuals or to other parts of the process. This allows the system to always keep track of tokens and their provenance in the context of arbitrary process changes.

REFERENCES