Make the Change Easy, Then Make the Easy Change
Kent Beck's advice for changing code: first restructure the code so the change becomes simple, then make that simple change.
Also known as: First Make the Change Easy, Then Make the Easy Change, Make the Change Easy, Kent Beck's Refactoring Rule
Category: Principles
Tags: software-development, software-design, refactoring, technical-debt, principles
Explanation
On September 25, 2012, Kent Beck posted: "for each desired change, make the change easy (warning: this may be hard), then make the easy change". It's one of the most quoted lines in software development, often shortened to "first make the change easy, then make the easy change".
The idea fits in one sentence, but it reverses how most people approach a change.
**The usual approach**:
You need to add a feature. The code isn't shaped for it. So you force the feature in: a special case here, a flag there, a copy-pasted function with small differences. It works. The next change is a bit harder. After a few rounds, every change is painful (see technical debt).
**Beck's approach, in two steps**:
1. **Make the change easy**: Refactor first. Restructure the code so the new feature fits naturally, without changing what the code does. Extract a function, separate responsibilities, introduce the abstraction the feature needs. Run the tests after each step
2. **Make the easy change**: Now add the feature. Because the code is ready for it, this step is often small and obvious
The parenthetical matters: "warning: this may be hard". Step one is where the real work happens. Sometimes it takes much longer than the change itself.
**Why it works**:
- **Two kinds of change, never mixed**: Refactoring changes structure without changing behavior. The feature changes behavior on top of a stable structure. Mixing both in a single step makes bugs hard to find and reviews hard to read
- **Smaller, safer steps**: Each refactoring step is easy to verify (see refactoring and test-driven development)
- **Better reviews**: A pull request that only restructures code, followed by one that adds the feature, is much easier to review than one that does both
- **The codebase improves over time**: Every feature leaves the code in better shape for the next one (a close cousin of the Boy Scout Rule)
**How to apply it**:
1. Before writing the feature, ask yourself: what would the code need to look like for this change to be trivial?
2. Get there with small refactorings, keeping the tests green the whole way
3. Commit the refactoring separately from the feature
4. Make the change
5. If the preparation keeps growing, stop and reconsider: maybe the change belongs somewhere else
Kent Beck explores the same idea at length in his book Tidy First?, which is about when and how to tidy code before changing it.
The principle also works outside code. Before reorganizing a process, a document or a note system, first make the reorganization easy.
Related Concepts
← Back to all concepts