Skip to content
Software Architecture Guide

Keep It Working

Explanation

Section titled “Explanation”

Keep It Working is a strategy for software that has built up maintenance needs. A full overhaul looks tempting, but it could break the system. So the team changes the software in small steps and keeps it running the whole time.

Why availability matters. Once a city builds its infrastructure, it must keep working. Established software is similar. Businesses depend on it and on its data, so it cannot simply stop while someone rebuilds it.

The city analogy. Cities rarely change all at once. Change happens a building or a block at a time, while the city as a whole keeps functioning. Software can change the same way.

Live feedback. The main strength of this approach is quick feedback. A change that breaks the working system is rejected right away. The team learns about a problem while the change is still small.

Integrate often. Integration means combining separate pieces of work. Putting it off is described as a recipe for misery. Frequent integration is the alternative to one late big-bang merge.

Related practices.

  • Daily builds. Microsoft, for example, requires a daily build of each product at the end of every working day.
  • Building large new subsystems off to the side, perhaps with separate teams, and then integrating them with minimal disruption.

Modern equivalent. The strangler fig approach, described by Martin Fowler, prefers gradual modernization over big-bang replacement, which usually fails. It replaces small, isolated components one at a time. Because each component is small, introducing new software carries less risk.

Example

Section titled “Example”

A company runs an old order system that needs cleanup. Rewriting it all at once could stop orders for weeks. Instead, the team replaces the invoice component alone and builds the whole system at the end of each day. If the new component breaks the build, the team rejects the change at once. Orders keep flowing throughout. The team then moves on to the next small component.

Trade-offs

Section titled “Trade-offs”

The approach lowers risk, but it asks for discipline. The team must integrate often and check every change against the running system. Large new subsystems still need extra care, because they are built on the side and only joined to the working system later.

Small steps with immediate feedback keep a working version available.

Diagram source 
flowchart LR
 A[Working system] --> B[Small change]
 B --> C[Build and test]
 C -->|Passes| D[New working system]
 C -->|Breaks| E[Reject change]
 E --> A
 D --> B

Checks

Section titled “Checks”
  • The document says the system must stay available while it is modernized, because the business depends on it and its data.
  • Changes are made in small steps and integrated often, rather than in one late big-bang integration.
  • Changes that break the running system are rejected immediately, for example through regular builds.
  • Large replacements are built on the side or one small component at a time, not all at once.
Section titled “Related”

Sources

Section titled “Sources”