Named Stable Bases

If you want to balance stability with progress, then: have a hierarchy of named stable bases that people can work against.

## Relationships

### To be applied before

* delineate the schedule for Named Stable Bases with Size The Schedule.

### To be applied after

* Build Prototypes is an instrument for Named Stable Bases.
* Named Stable Bases is an input for Incremental Integration and Private World.
* Named Stable Bases provides possible context for Take No Small Slips.

### Alternatives

* Programming Episode is Named Stable Bases in the small.

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

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

## Problem

**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.

## Solution

**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.

## Discussion

A prototype can be an expedient for one of the Named Stable Bases; see Build Prototypes.

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).

Programming Episode is an example of this pattern in the small.

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html