The Small Team Spirit

As was true for Borland's QPW, this product is developed by a small team. Small teams can achieve results that would be impossible in a traditional organization. It makes anthropomorphism feasible. It gives everyone a feeling of connectedness. It smooths communication, and in fact enables communication dynamics that may lie at the heart of concurrent engineering.

"I think I'm going to need this soon," Bryan yells down the hall to Dave about a module with changes that must be coordinated with Bryan's fixes. It's mid-morning, and he knows that before the morning is over, he'll need Dave's module so he can test his own work out. Dave knows that unless he stops what he's doing and turns to the module Bryan asked for, that Bryan will become blocked. Dave drops what he's doing and moves to finish up the work he needs to do to support Bryan. At about 2:00, Dave yells down the hall, "Here it is." Bryan is now in shape to test after only a short delay, and Dave goes back to what he's doing, without ever having been idle.

An exceptional instance? No: interrupt mode is the modus operandi of the whole group, in the interest of minimizing wait states. It is the InterruptsUnjamBlocking pattern. Wait states can add substantially to product interval. The micro-parallelism of this process alleviates much of the blocking one finds in large projects. Just as in processor scheduling, interrupts reduce the latency to service a request. If the context-switch overhead is low enough, an interrupt-driven development's throughput will be about the same as for any other approach. It takes close-knit communications to make it work.

How do these communications take place? I asked if they held periodic team meetings. "Not if we can help it," was the reply. Team members have a small number of small three- or four-person meetings during the day. Yelling up and down the hallway is de rigueur. It is unlike Borland, where much more of the dialogue seems to have taken place at a round table under the banner of architecture. But the underlying principle — close-knit communication — is the same.

This approach leads to an unconventional view of time and schedule. Most software development projects are monochronic societies: They believe time adds up algebraically. This organization seems to be more polychronic: with parallelism and task shuffling, time becomes fluid and can be manipulated. The interrupt-driven nature can be somewhat nerve-racking, and carrying on in parallel with people outside the team (e.g., in front-end and back-end processes) can be uncomfortable. But the resulting productivity gains are high.