Incremental change
Incremental change has two sides:
- Development: developers can make small changes easily, because the code is well tested and well structured.
- Operational: those changes can be deployed quickly and safely, because the deployment pipeline and runtime support it.
You need both. Easy code changes that take a month to release aren’t incremental, and fast deploys of a tangled codebase are risky.
Enablers
Section titled “Enablers”| Practice | Why it helps evolution |
|---|---|
| Deployment pipelines / continuous delivery | Every change goes through the same automated checks, including fitness functions. The pipeline is where governance runs. |
| Small batches | Smaller changes are easier to understand, test, and roll back. |
| Feature toggles | Separate deploying code from releasing a feature. Remove toggles once done, or they become debt. |
| Trunk-based development | Avoids long-lived branches that turn into big, risky merges. |
| Canary and blue/green releases | Expose a change to a small slice of traffic and watch the fitness functions before going wider. |
| Hypothesis- and data-driven development | Treat a change as an experiment with a measurable expected outcome. |
| Infrastructure as code | Infrastructure changes get the same review, test, and pipeline treatment as application code. |
Migration patterns
Section titled “Migration patterns”- Strangler fig (Fowler): put new functionality beside the old system and route traffic to it gradually until the old system can be removed.
- Parallel change / expand and contract: add the new form, migrate consumers, then remove the old form. Works for APIs, schemas, and infrastructure modules.
- Branch by abstraction: put an abstraction in front of a component, build the replacement behind it, then switch.