http://people.csail.mit.edu/jaffer/CNS/ICUIAS
	Incremental Change: Unsafe in Any Size

Among engineers and managers, the assumption that a "small change" to a computer program or electronic design can be executed without a design qualification cycle is so widely held that challenging this idea can provoke screamed insults and accusations of sabotage.

The strength of this conviction is evidenced by engineers committing into source control changed files with syntax errors not just once, but twice in succession. Some engineers accustomed to calculating error rates and probability distributions apparently do not realize the same rules apply to their work.

Incremental Change Methodology

Incremental change is a powerful design and development methodology for complicated technological systems. The components of this methodology are:

• A regression suite of tests covering the major areas of operation.
• A system which passes (some of) the regression suite tests.
• A version archive of the design sources.

The system is developed by making changes to the latest working version and debugging it to pass the regression suite. As new capabilities are developed, regression tests are added or augmented to test them. Only design sources passing the regression suite are committed to the archive and released.

How does this methodology differ from undisciplined development? People working on separate parts of the design each start from the last working version. When a change is debugged, it is committed to the archive; other developers' sources are not updated automatically. Checking that updates don't interfere with a developer's working version is a deliberate process by the developer. Alternatively, two changes can be integrated after they are individually validated. The Concurrent Versions System supports both methods of merging changes.

Even in the eleventh hour (where undisciplined sources take damage), stimuli which provoke failure are immediately added to regression, and last minute "this should fix it" changes are not committed unless they pass this and all other regression.

Benefits of Incremental Change

The goal of incremental change is to never lose "the magic" of a working system. Having a succession of functional versions means that QA usually has prototypes to test; they will rarely be idled pending replacement of a bad release.

With ICM, new development threads can be started at any time. With the alternative, initiating a thread must either wait for harmonized release or it interferes with work-in-progress.

ICM sources change little from generation to generation. Time invested studying the source and adding comments reaps benefits over long periods.

Safety, Not!

But one benefit that incremental change does not confer is safety. A single misplaced keystroke can render a comment or other supposedly inert change into a syntax error. The syntax-error commits mentioned in the introduction were changes smaller than 30 characters!

Long experience teaches that project-wide discipline in archive hygiene is the surest road to smooth and harmonious development. Source changes of any size should always be regression tested.