This video uses the art of bonsai as a metaphor to explain a powerful software development principle from Kent Beck: “First make the change easy, and then make the easy change.” It argues that complex modifications should not be tackled in one large step, but rather broken down into a preparatory phase followed by a simple implementation.
The Bonsai Analogy for Future Changes
The speaker demonstrates this concept on a pre-bonsai tree. The long-term goal is to make a tiny branch the new crown of the tree, a significant change that will take years. Instead of waiting, he begins the preparatory work now by wiring and bending larger “sacrificial” branches out of the way. This initial, difficult work is the “make the change easy” step, which will make the final goal much simpler to achieve in the future.
Applying the Principle to Software Development
This two-step process is directly applicable to software engineering and is related to the Open-Closed Principle. The idea is to prepare the codebase for an upcoming feature or modification before actually implementing it.
- Step 1: Make the Change Easy (Refactoring): This is the preparatory phase where you restructure existing code without changing its external behavior. The goal is to create the ideal conditions for the new feature. This phase should be heavily supported by automated tests (unit, integration, etc.) to ensure no functionality is broken. This might be the harder part of the process.
- Step 2: Make the Easy Change (Implementation): After the refactoring is complete, adding the new feature or making the desired change becomes a simple, straightforward task with minimal risk.
Key Benefits and Conclusion
The primary advantage of this approach is the separation of concerns. It cleanly divides the act of improving code structure (refactoring) from the act of changing its functionality. This separation leads to several benefits:
- Reduced Risk: By validating the refactoring with tests before introducing new logic, you minimize unintended consequences.
- Easier Code Reviews: It’s much simpler to review two distinct changes (a pure refactoring and a simple feature addition) than one large, complex change that mixes both.
In conclusion, the video advocates for a deliberate, disciplined approach. By first investing time in refactoring to prepare for a change, developers can make the final implementation significantly safer, simpler, and more manageable.
Mentoring question
Reflect on a recent complex feature or change you implemented. Could you have applied the ‘make the change easy, then make the easy change’ principle to break it down into a safer refactoring step followed by a simpler implementation step?
Source: https://youtube.com/watch?v=c95vHwCTJeU&si=R7CXPUPefXxoXfz0
Leave a Reply