A Piecemeal Architecture Process


QPW development was highly iterative. To understand the nature of the iteration, one must understand its ramifications for architecture and implementation. One must also understand the culture by which changes were approved and how decisions were made. This takes us into the realm of project meetings, always a topic of interest in a large development organization.

The core architecture team met daily to hammer out C++ class interfaces, to discuss overall algorithms and approaches, and to develop the basic underlying mechanisms on which the system would be built. These daily meetings were several hours in duration; from what I heard, the project was made more of meetings than anything else. Everyone's external interfaces were globally visible, and were globally discussed. The product structure was built on the domain expertise brought to the table by domain experts, but it was socialized and tempered by the needs of the product as a whole.

In spite of the intense meeting-oriented development culture the project built around its architectural development, class implementations were fleshed out in private. Individuals were trusted with doing a good job of implementation: after all, project members were acknowledged experts in their domains. Code reviews were rare. The trust and respect engendered by this domain expertise made it possible to focus meetings on system-level issues.

There are three project principles worth noting about the QPW organization's communication architecture:
  1. Meetings are not a bad thing. While we all cringe at the thought of a project centered on a meeting that carries over from one day to the next throughout early development. But our fear of meetings likely comes more from our memories of the ineffectiveness of our meetings, not from their frequency. At the First International Workshop on Software Process, I polled several process luminaries with the following question: Suppose I am among the most mature software organizations in the world (a CMM Level 5). [BibRef-Humphrey1992]. How much of my time do I spend in meetings? Responses from Vic Basilli, Watts Humphrey, and Barry Boehm ranged from 30% to 50%. Project communication, a shared vision, and meetings are important and productive if meetings are properly conducted.
  2. Development takes place on two levels:architecture and implementation. There is an architectural thread, and a development thread; both are ongoing, and they interact with each other strongly. New implementations suggest architectural changes, and these are discussed at the daily meetings. Architectural changes usually require radical changes to the implementation. The implementors' ability to quickly reflect those changes in their implementation is key to turning around architectural changes quickly; this is due in large part to ArchitectAlsoImplements. This is where the outstanding productivity of the project members comes into play: Their incredible productivity supports iterative development. There may be a third development thread — product management and marketing — that goes beyond the scope of this inquiry.
  3. The development interaction style is a good match for the implementation technology the group had selected. Object-oriented development leads to abstractions whose identity and structure are largely consistent across analysis, design and implementation. Classes hide implementations and localized design decisions, though their external interfaces are globally visible. Mapping C++ classes and people close together made it possible for developers to reason about the implementation off-line, away from the meetings that dealt with interface issues.

Notice this is contrary to the commonly presumed model that the object paradigm makes it possible for an individual to own a class, interface and all, with a minimum of interaction with other class owners in the organization. It should be emphasized that classes are good at hiding implementation and detailed structure (e.g., in derived classes) but that they are not good at reducing the ripple effect of interface changes. In fact, because interactions in object-oriented systems form an intricate graph, and interactions in structured procedural systems usually form a tree, the ripple effect of interface changes in an OO system can be worse than in a block-structured procedural design.

A question frequently posed to organizations using iterative techniques is: "How do you mark progress or do scheduling?" For QPW, there are two parts to the answer. First, they relied on experience sizing similar jobs, and found the overall estimates to be satisfactory. Second, they kept multiple sets of books internal to Borland to achieve different goals. The hardest of the dates was owned by (and not divulged by) the parts of Borland that own the financial books. A "real" street date was needed so the company could provide planning and resource support to the development. But internal scheduling provided incentive, focus, and pressure for development to move ahead. Project management and corporate executives presented deadlines to the development teams that failed to telegraph the business view of the schedule, presenting a more compressed schedule for development than the business case allowed for. You see this approach reflected in the SizeTheSchedule pattern.