More Thoughts on the Mikado Method

Even in a small refactoring, as in the previous example, it’s easy to get lost and to forget things. Building the Mikado graph helps you track where you’ve been and where you still need to go.

Working backward is an important part of the Mikado Method. The opposite, typical approach involves taking the code as it is and attempting to refactor toward a somewhat-vague end goal. You have a rough vision of what the solution should look like when you get there.

The forward approach can get you where you want to go, but its haphazard approach creates some problems. It’s easy to make a number of code changes that lead nowhere. You resist starting over, because that will require you to decipher all the steps you’ve made so far. More often than not, you choose to slog forward, potentially leaving some of the less-than-ideal code changes in place.

As mentioned earlier, sometimes you get only halfway to the end goal and are forced to abandon partial solutions. Incomplete refactoring attempts can make the codebase quite confusing.

Where the Mikado Method shines is with a larger refactoring that might take several days or more to accomplish. Since most of that time is exploration and analysis time, you can distill the actual work to a simple script represented by the Mikado graph. Further, the act of repeatedly attempting solutions and reverting when there’s a problem means that you will have streamlined the process of reapplying steps in a solution. (You might even keep little snippets of code handy as you build the graph.)

With a complete, well-practiced Mikado graph, you might be able to distill a couple weeks of exploration and analysis into a couple-hour script. You can subsequently apply the script during off-hours in order to effect broad, sweeping changes across your system. You tell your teammates to ensure they’ve integrated all code before leaving for the day, you apply the script, and worst case you revert it if there are problems. Your team comes in the next morning and pulls your large-scale change. Your work creates minimal impact for them, and vice versa.

You’ve experienced the core of the Mikado Method. However, I highly recommend exploring the technique in further detail. The Mikado Method book (Behead Your Legacy Beast: Refactor and Restructure Relentlessly with the Mikado Method [BE12]) will supply you with everything you’ll want to know. It also provides an excellent summary of principles for dealing with legacy systems.