What is the Mikado Method?

Ola Ellnestam, Daniel Brolund, http://www.manning.com/ellnestam/

This article is based on The Mikado Method, to be published in Spring 2014. This eBook is available through the Manning Early Access Program (MEAP). Download the eBook instantly from manning.com. All print book purchases include free digital formats (PDF, ePub and Kindle). Visit the book's page for more information based on The Mikado Method. This content is being reproduced here by permission from Manning Publications

How many times have you wanted to fix something, and while doing it not break the code? Or think of all the times that development work hasn't started from an empty codebase and you've inherited the constraints of the previous team. What you'd normally do is look over the documentation left behind; if there are automatic tests you'd see if they pass. Well, what happens if there aren't any tests left behind, and all that's left is the source code? How do you understand what's going on without breaking the code? In this article, based on chapter 1 of The Mikado Method, the authors talk about how the Mikado Method is a structured way to make significant changes to complex code.

The Mikado Method is a structured way to make major changes to complex code. When a codebase gets larger and complicated, as they often do, there usually comes a time when you want to improve portions of it to meet new functional requirements, new legal requirements, or a new business model. You may also just want to change it to make it more comprehensible.

For small changes you can keep things in your head, but for larger ones the chances of getting lost in a jungle of dependencies or in a sea of broken code increases dramatically. The Mikado Method helps you visualize, plan, and perform business value-focused improvements over several iterations and increments of work, without ever having a broken codebase during the process.

The framework that the Method provides can help individuals and whole teams to morph a system into a new desired shape. The Method itself is straightforward and simple and can be used by anyone at any time. In this article, we are going to look at the core concepts, benefits, and when you can use it.

Basic concepts

There are four basic and well-known concepts that summarize the "process" of the Mikado Method: Set a goal, Experiments, Visualization, and Undo. These concepts, when used together in the Mikado context, create the core of the method itself.

Without these key pieces, the method wouldn't be able to help you make changes without breaking the codebase. By no means are these concepts new, but put together they become very powerful. In the context of the method they may serve a different purpose than how you might know them.

Set a goal

To set a goal, think about what you want for the future. For instance, if you have a package with several web services that need to grow but it is already responsible for too much, perhaps what you'd want for the goal to be is "to have the admin services be in a separate package that can be deployed without the customer web services."

After you clearly state the goal, write it down. The goal serves two purposes: 1) represents a starting point for the change 2) determines if the method has achieved success or not.

Experiments

An experiment is a procedure that makes a discovery or establishes the validity of a hypothesis. In the context of the Mikado Method you use experiments to change the code so that you can see what parts of the system that breaks. Whatever is breaking gives you feedback on what types of prerequisites are needed before you can actually do that change. A typical experiment could be to move a method from one class to another, extract a class or reduce the scope of a variable. Those prerequisites are what you visualize.

Visualization

Visualization is when we write down the goal and the prerequisites to that goal.

Figure 1. A Mikado Graph with a goal and two prerequisites.

The picture shows a small map and the content of such maps normally comes after we've experimented and are ready to create what we call a Mikado Graph. Beside the changes to your codebase, the map is the only artifact of the Mikado Method. A refactoring map is the goal plus all the prerequisites of that goal, and it tells us what our next step is.

Undo

When an experiment for implementing a goal or a prerequisite has broken your system, and you have visualized what you need to change in the system to avoid it breaking, you want to your changes to restore a previously undo working state. In the Mikado method, you'll always visualize your prerequisites, and then undo your breaking changes. This process, experiments, visualization, and undo, is iterated for each of the prerequisites. In order for the experiments to be meaningful, the code needs to be in a known working state when the experiments start. If this isn't making sense to you now, it will when we get to the recipe where we take you step by step through the method.

Of these four concepts, the undo part is what people struggle with the most, because at first, undoing feels very unintuitive and wasteful. It's not waste, it is an important part of the learning.

When to use the Mikado Method

If we want to be successful software developers, we need to learn how to morph an existing system into a desired new shape.

Maybe you have tried to implement a new feature, but the system is constantly working against you? Maybe you've thought once or twice that it's time to stop developing new features for a while and clean up a bit? Maybe you've done a refactoring project, or you have tried to do a bigger improvement to your system, but wasn't able to pull it off so you just threw it all away?

We bet that you've been in at least one of the situations described above, and we know that the Mikado Method and this book could have helped. It doesn't really matter if the code was yours or someone else's; it doesn't matter if the code was old or new. Sooner or later that shiny new greenfield project where everything can fit in your head and changes are easy to perform will become more and more complex. As time passes the code fades just like grass does when it's heavily used and visited. The green grass field turns into a brown field, and sooner or later you, or your successors, become afraid of changing code. So, let's face it, we're stuck with brownfield development and we need to be able to morph code we're afraid of touching, in mid-flight. Let's look at a few common scenarios where the Mikado Method can help.

Improve a system architecture on the fly

When you've hit a wall and a design doesn't lend itself easily to change developers get frustrated. It could be an API that is hard to understand and your customers are complaining or your nightly batch jobs barely make it because the data that needs to be processed has increased by 10 times. It can be times like that when the code seems so complex and the only way to solve your problems is by stopping development and focus solely on improving the codebase for awhile or maybe run an improvement effort as a side project. Improvement projects make stakeholders nervous and rightfully so, because they see nothing of value coming out. The Mikado Method helps in changing the architecture in small steps, allowing improvements and continuous delivery of new features to co-exist, in the same branch.

Brownfield development

Brownfield development is probably the most common situation developers are in and in order to continue business upgrading and improving an existing application infrastructure is necessary. Whether it's adding a new feature, or altering functionality, the Mikado Method helps in these situations because it works with what you've got and improves upon it. Just like any other codebase, these also needs to change for several reasons, but often you don't know the whole code base inside out so changes become inefficient, or down right scary. The Mikado Method provides a way to take on a reasonable amount of improvements for each feature.

Refactoring projects

Imagine that you want to extract a reusable module in a heavily entangled system, or to replace an external API that has leaked deep into your codebase. Ideas and improvements like that are really big and they usually take several weeks, or even months, to complete. Making improvements for large tasks require a nondestructive way forward. The Mikado Method helps you uncover that nondestructive way and keeps you on track even if the effort takes months. This way refactoring projects can be avoided entirely.

Benefits of the Method

We now know that the Mikado Method is a way to improve code more without breaking it, what situations we'd be in when we'd want to use it, now let's look at the benefits before we dive into how it works.

Stability to the code base

Stakeholders will love the Mikado Method because it provides stability to the codebase while changing it. No more, "We can't release now, we're ironing out a few wrinkles." The path to a change becomes a nondestructive one from lots of small changes instead of a big integration in the end. Due to its visual nature, interested parties can also follow along easily and watch the map evolve and then see how the changes are being performed and checked off on the map.

Increases communication and collaboration

From a teams perspective it works really well too. By communicating the change map collaboration becomes easier and a change effort can be spread across the team. This way the whole teams competencies, abilities, and existing knowledge can be leveraged and the workload can also be distributed throughout the team.

Lightweight and goal focused

Last, but not least, the Mikado Method supports an individual by being quick to learn and easy to use. The Method has very little ceremony and consists of a lightweight process that requires almost no additional tools, just pen and paper or a whiteboard. In its simplicity, it still helps you keep your eye on the price. As a bonus, you can use the refactoring map you get from the process to assist you when you reflection over the work done and this improves learning.

Summary

You saw that the idea behind the Mikado Method is to remove the least amount of obstacles at a time in order to achieve real results without breaking code. We discussed some of the benefits and when to use the Mikado Method.

---

Agile Resources

Scrum Expert

Agile Videos and Tutorials

Project Management Planet

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2013 issue of Methods & Tools