Named Stable Bases ★

A stable base with a name on it...

... the project schedule has been laid out and development has started.

✥ ✥ ✥

It is important to integrate software frequently enough so that the base doesn't become stale, but not so frequently that you damage a shared understanding of what functionality is sound and trusted in an evolving software base.

If you try continuous integration, developers struggle to follow a moving target and there is no shared sense of quanta of functionality at any given time, or quanta of progress from week to week. But if it's too long between integrations, developers become blocked from making progress beyond the limits of the last base.

So while stability is a good thing, the project must always make progress -- and, more importantly, the stakeholders must perceive that progress is being made.

Therefore:

Stabilize system interfaces — the architecture — about once a week. Give the stable system a name of some kind by which developers can identify their shared understanding of that version's functionality.

The names need not be elaborate; they can simply be a load number. The names should, however, be easy to remember, to identify with the correct version of software, and to distinguish from each other. The idea is to provide some sort of handle that people can use to communicate about a stable base.

Other software can be changed (and even integrated) more frequently.

✥ ✥ ✥

A prototype can be an expedient for one of the NamedStableBases; see BuildPrototypes.

The project has targets to shoot for and benchmarks whose accomplishments can be trumpeted to customers. This affects the Customer view of the process, and has strong ramifications for the Architect as well.

The pattern was initially pointed out by Dennis DeBruler at AT&T.

The main point of the pattern is that a project should schedule change introduction so the effects of changes can be anticipated. It is less important to publish the content of a change (which will go unheeded under high change volume) than for the development community to understand that change is taking place. It is important not to violate "the rule of least surprise."

It can be helpful to have, simultaneously, various bases at different levels of stability. For example, one AT&T project had a nightly build (which is guaranteed only to have compiled), a weekly integration test build (which is guaranteed to have passed system-wide sanity tests), and a (roughly biweekly) service test build (that is considered stable enough for QA's system test).

ProgrammingEpisode is an example of this pattern in the small.