The Culture


This organization has been around in one form or another for about 15 years. They have a long history of prototyping and building small systems. About four years ago, the organization started working on trials to prove in their product concepts. Development started in earnest about two years ago. The development team currently has about 8 people. Most (all but two at the debriefing) have families. The group is demographically diverse.

The project has an excellent history of meeting impossible delivery dates, owing to much hard work. The team typically works 50- to 60-hour weeks, some working 60- to 70-hour weeks over a five-month spurt. The team is egalitarian in the sense that everybody writes code, but is non-egalitarian in that everybody brings their own realm of expertise to the table (which is an important factor we explore later under "Code Ownership.")

People do much of their own risk management. As the meeting got started, Peter told how he was going to add line splitting to the architecture. That was going to make more work for Pat. Pat was playfully unhappy about the change, but it was a design change the team had decided some time ago that it had wanted. The project had been granted a one-month extension in its schedule, and Peter had taken the initiative to do a redesign of the part of the system that had been causing them to use resources inefficiently.

Parallelism is key to the organization's success. The organization got its start when presented with an ambitious scenario:

Conceptualize and deliver a system prototype in four to five months. Almost coincidentally, the requirements, testing, and design all converged on the same date. It worked, and converged faster than anyone imagined possible. The small team size, the excellence in systems engineering, and lack of dogmatism among team members were major factors in the success of the prototype. The organization became more introspective about their concurrent engineering approach to development, and turned it into a way of life for themselves. The technique that made the prototype successful was carried into the development of the product itself. It is this way of life that I had come to study.

And the introspection isn't complete. There is still a feeling that part of what makes them successful is purely instinctive. Peter even worried that if I surfaced process understanding into their consciousness, that it would affect the way they worked--because it would establish a new introspection framework--and potentially damage the delicate balance of magic that propelled them to success. While there is a slight chance that the Heisenberg phenomenon could take them in that direction, there is equal or greater probability that such a discussion could open their eyes to possibility for improvements.

The programming language is C, the development environment is UNIX. (Note that they use neither object-oriented approaches nor C++, staples that have become stereotypically associated with high productivity and best current practices.) The product has performed well in the field. Three installations have been running for 7 months, with only 3 unplanned outages to their credit totaling less than 8 hours: better than 99.94% uptime. The total number of faults found in the field has been about 25, out of which 20 have been addressed at this writing.

The organization's culture, self-image, and process have a rich human element that precipitates from the small team environment. These issues merit their own section later in this chapter.