Crafted Reading List: The Mikado Method
“The initial focus of the Mikado Method is effectively dealing with a messy reality. The long-term goal, however, is to understand the forces that drive organizations to create bad code in the first place so we can avoid creating more code that our successors will have to struggle with unhappily. When we’re confronted with the normal levels of complexity in today’s software, we can’t keep everything we need in our heads at once.”
Why we like it:
Almost anyone that has participated in pair programming with me in the past couple of years has encountered the Mikado Method. This book has fundamentally changed how I approach difficult refactorings and everyone I’ve shown it to has loved it. Everyone has encountered that refactoring or user story that leads to a long-running branch that ends up weeks out of sync with the rest of the codebase. You finally think you’ve completed your masterpiece when a merge or rebase crushes your hopes. Or perhaps you’ve been the product owner or product manager wondering if you’ll ever get your story complete and the engineers keep telling you that they’re refactoring. The Mikado Method solves both of these problems and many more.
The Mikado Method gets its name from the children’s game of pick-up sticks. It provides a simple, iterative framework for breaking down complex changes to software code. At its core, you start by defining a goal, trying one change, and noting how that change causes other failures. You build up a graph consisting of each of these steps and their dependencies and as you find these successful changes, you commit them to source control and check off the graph. The graph can be proudly displayed on a whiteboard for the whole team to see. This helps the product managers and product owners gain visibility into the voodoo that is refactoring and shares context with the engineering team, making it easy to rotate pairs through the refactoring process.