An Overview of the Mikado Method
The complete process follows an initially daunting nine-step cycle. Once you’ve worked your way through the cycle a few times, however, it won’t be far from second nature. You’ll ingrain it even faster than the TDD cycle.
-
Draw the Mikado Goal, an end state you want to reach.
-
Implement the goal in a naive manner.
-
Find any errors.
-
Derive immediate solutions to the errors.
-
Draw the immediate solutions as new prerequisites.
-
Revert code to its initial state if there were errors.
-
Repeat steps 2 through 6 for each immediate solution.
-
Check in code if there were no errors; mark the prerequisite goal complete.
-
Is the Mikado Goal met? If so, you are done!
Most of the days or weeks you end up spending on a large refactoring initiative isn’t spent on the actual code changes themselves. The size of each change is usually small (although there might be a large volume of changes). The time is instead spent on the requisite analysis and mental probing that you undertake. “Where are all the clients that call this function? If I change them, what other clients are impacted? What does this code do exactly? How am I going to prove that this still works?“
With the Mikado Method, you separate the analysis from time spent applying code changes based on that analysis. You reduce the code changes to a simple change graph, or Mikado graph, a script of sorts. The graph depicts a primary goal—the Mikado Goal—and a set additional goals on which the primary goal depends. You repeat, often, attempts to apply portions of the change graph to the codebase. The repetition teaches you to make the correct code changes with high confidence and speed.
Building the Mikado graph leaves you with visual summary of the tasks that you must accomplish. You can optionally farm out pieces to your teammates to expedite completing the Mikado Goal. The graph provides a focal point for cross-team communication and coordination.