[ Home | Resume | Programming | Engineering Philosophy | Family ]

The Pyramid of Good Execution

It is widely accepted that engineering execution (roughly defined as all activities downstream from specification , but upstream from production) is often the difference between success and failure in the marketplace. However, concrete distinctions between good and poor execution are hard to come by. Most people cite the obvious (e.g. bright, hard-working contributors) and the intangible (e.g. teamwork and morale), but such insight offers little operational guidance. This essay attempts to recite specific, detectable (if not measurable) attributes of well-executed projects.

The principal misconception about execution is that it is primarily a function of high-visibility activities (e.g. design), and that other related activities exist primarily for assessing the quality of execution. In my experience, execution itself is in fact increasingly dependent on decreasingly visible supporting activities, as illustrated by the following diagram:

The Pyramid of Good Execution [ PDF ]

Since supporting infrastructure is typically neglected, there is usually a great deal of leverage in improving it, even if that requires compromising high-visibility activities.

Elegant, Robust Design

Design quality is an obviously important component of good execution. Good design is elegant, meaning that it takes full advantage of all reliably known information. However, good design is also robust, meaning that it does not depend on information that is not reliable (for example, because it might change).

Nonetheless, even with the best possible design practices, the fact remains that...

Anything that isn't verified is most likely broken.

Therefore, the design effort is entirely reliant on the verification effort.

Complete, Coherent Verification

Since unverified features are usually defective, the verification effort must be complete, meaning that it fully verifies all features. One should not rely on coverage metrics to determine when the verification effort is complete.

Since it is also necessary to verify arbitrary combinations of features, the verification effort must also be coherent, meaning that there is a single verification platform that covers all the features. An incoherent verification effort requires more resources to be complete, which is problematic because even coherent verification requires at least twice as much effort as design on contemporary state-of-the-art projects.

However, because design changes are a normal and commonplace part of the verification cycle, even the most thorough verification effort is worthless unless it can be applied to an arbitrary number of design iterations. Therefore, the verification effort is entirely reliant on the build system.

Reliable, Efficient Build System

In order for the results of the design and its verification to be reproducible, the build system must be reliable. Without a reliable build system, it is difficult to draw any reliable conclusions about a given state of the design. Unfortunately, most build systems are based on make(1), which tends to be unreliable (see "Recursive Make Considered Harmful" ). Alternatives include Jam/MR .

Unreliable build systems can sometimes be made reliable by consistently clean-building, meaning that all builds are from scratch regardless of what has changed since the last build. However, clean-building is also very inefficient. The problem with an inefficient build system is that it dramatically increases the length of the design/verification cycle, which significantly slows the rate of progress.

Still, even the best build system in the world won't help you unless you are building the intended version of the design and verifying it with the intended versions of the tests. Therefore, the build system is entirely reliant on revision control.

Functional Revision Control

In order that individuals can operate with a stable configuration of versions that are appropriate for the intended activity, a revision control system that supports static isolation and branching is required. See "On Concurrent Development" .

Effective and fully functional revision control is so fundamental that it is often taken for granted. In reality, it requires quite a bit of attention to get right, and the consequences of getting it wrong permeate all aspects of the project, as well as the operation of the organization in general.

Anders Johnson, last modified $Date: 2002/02/05 $

[ Home | Resume | Programming | Engineering Philosophy | Family ]