Over a million developers have joined DZone.

The Mikado Method

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

Have you ever considered a large scale change to a piece of software? Something that you can’t possibly get done within a single day? Did you refrain from the change because of that? Or did you hack away on your code hiding in a corner for week. Having nightmares about merging it with all the other changes that happened in between?

If you know this situation read on. You’ll want to learn about the Mikado Method.

The Mikado Method has its name from the game Mikado. In the game you try to remove sticks without moving any other sticks of the game. In order to find a stick you often carefully move one that looks promising. If it moves without problem you remove it. If you find that it touches another stick you leave it for now and try a different one, often the one touched by the first. The Mikado Method works just the same:

  • You want to change the software you are working on. Often some kind of refactoring, but maybe you want to add a feature which in turn needs some refactoring of the existing application.
  • You start with the change in the most simple way you can think of.
  • If this works: Great, commit it to version control. If not, you take note of the things you have to change in order to make the first change.
  • Then you rollback your work!!
  • You iterate with one of the necessary changes

There are a couple of key elements in this process:

  1. You pick a move without to much analysis. The compiler and your tests will tell you if it works. Note: If you don’t have tests you are in deep trouble, but you knew that, right? Good news: you can use the Mikado Method while writing tests.
  2. If it does not work you try not to fix problems, but you rollback your changes.
  3. You use a simple notation to write down everything you need to change. This way you can see what is left to do and where you can try the next step.

The simple notation is just a simple directed graph. You can draw it with pen and paper or a white board. Since it can become pretty large I prefer a simple graph editor like yed.

I tried the Mikado Method for two tasks lately and it works like charm. I was never far a way from compiling code. And I had a good overview of all the things that I needed to do and also the order in which I had to do those things. Even after switching to other tasks for almost a week I could pick up my work without much delay.

There is just one problem I encountered with the Mikado Method: How to handle cycles in the graph you are building. From time to time I encountered such cycles like: do X; in order to do X I need to do Y; in order to do Y I need to do Z; I have to do X before I can do Z. I’m not sure if this was actually due to the fact that I was dealing with dependency problems in the first place, but I could solve the problem every time by removing some cyclic dependencies in the classes involved.

So that’s my little introduction to the Mikado Method. Obviously I didn’t come up with it and if you are completely confused by my rambling, or if you want to learn more about the Mikado Method you should go to its website. There is a free preview of a book. Its where I learned everything I know about the method.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.


Published at DZone with permission of Jens Schauder, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}