Home of the Mikado Method

The Mikado Method Sweetspot

Ola Ellnestam — Fri, 12 Aug 2011 00:17:43 +0000

From the book, 5.1.3 ‘Large scale improvements’:

When large portions of the code is changed the whole team will have to be engaged, and everyone needs to know the goal to be able to help out and understand. The team also has to communicate outside of its immediate vicinity, especially if the change is based on an external goal.

This is the perfect situation for the Mikado Method.

As the code undergoes these changes work is probably spread out over several days, weeks or months, and can benefit a lot from being carried out by several developers on a team. Putting the Mikado Graph on a whiteboard during this period of change is a great way to communicate that goal, the progress and its current state. External stakeholders, managers and other people with interest in the progress are also more likely to get involved if they can see what is happening.

Moved the Mikado Method code on github

danielbrolund — Sun, 20 Feb 2011 21:25:01 +0000

We just split and moved the Mikado Method code examples and exercises on github.

The new location is a github organization for the Mikado Method:

https://github.com/mikadomethod

(Old location: https://github.com/brolund/mikadomethod)

The examples are now split in separate repositories for better separation of concerns.

The examples are

https://github.com/mikadomethod/kata-java
The example from the book (Chapter 2).

https://github.com/mikadomethod/kata-dotnet
The example from the book, in C#.

https://github.com/mikadomethod/space
Some messy code containing a solar system simulation and an breakout embryo, all in one. We intent to specify some good goals to practice larger refactorings and restructurings.

https://github.com/mikadomethod/simwar
Another example. We intend to give you some hints on meaningful goals here as well.

The Mikado Method book

danielbrolund — Wed, 04 Aug 2010 12:22:32 +0000

Update:

We moved this page to http://mikadomethod.wordpress.com/book/

Mentions of the Mikado Method

danielbrolund — Sat, 05 Jun 2010 12:47:07 +0000

We will try to gather mentions of the Mikado Method here. If you know of an article that is not in this list, please let us know and we will update the list. The mentions can be both positive and negative. It is likely that the method works better in some cases and worse in others, so we would like to see that as well.

In the twitter flow you find it here

http://twitter.com/#search?q=Mikado%20Method

Speaking schedule

danielbrolund — Tue, 06 Apr 2010 19:36:28 +0000

Upcoming talks about the Mikado Method:

Øredev in Malmö, Sweden, November 12

Previously, the Mikado Method has been presented at the following places:

Agile2010 in Orlando FL, USA, August 9-13

XP2010 in Trondheim, Norway, June 1-4

SPA2010 in London, UK, May 16-19

XPDay 2009 in London, UK, December 7-9

SDC2009 in Gothenburg, Sweden, March 24

We are of course interested in speaking at your conference or company, please contact us.

Step size

Ola Ellnestam — Thu, 01 Apr 2010 13:29:11 +0000

Mikado method and step size

The Mikado Method in under a minute

Ola Ellnestam — Tue, 02 Feb 2010 20:13:13 +0000

For those of you who wonder what the Mikado method is and don’t have the time to read through a lot of text. This one is for you:

The Mikado Method by Ola Ellnestam and Chris Matts

Introduction to The Mikado Method

Ola Ellnestam — Wed, 09 Dec 2009 16:14:41 +0000

A couple of years ago, Ola Ellnestam and Daniel Brolund was working on a project where the code was a big ball of mud, or at least well on the way there. Global variables and singletons all across the code base, circular dependencies, deep and fragile inheritance hierarchies etc. The Technical Debt was everywhere.

Copy’n’paste?

All of a sudden we were supposed to deliver to a new client and the interest on our loan went through the roof. The reptile response from several developers on the team was to copy most parts of the code base to a new project and modify the code there. This would double our debt, but decrease the interest temporarily, until the next client would drop in. We fought with all we got to avoid doubling our debt and in the end we had convinced everybody that we could re-factor the code-base, just give us a week or two…

The Hydra

Our approach was that we should do what we needed to do, fix all the compiler errors, run all the tests, check-in, done. Yeah, right…

We did what we wanted to do, got about 20 compiler errors and started fixing them. When we were just about done, the compiler could move a step forward and showed us yet another bunch of errors. When trying to fix them we had to make new refactorings, that in turn created new errors. So we went on, and every day on the daily stand-up we said that “We just have a couple more errors to fix, but we will probably be done today or tomorrow”. Yeah, right…

After more than two weeks of working like this, with 1200+ files checked out, 200+ compiler errors we had to face it. We would never make it. We were trying to behead the Software Hydra, but for every head we cut off two more grew out. We had to make the tough decision to revert everything we had done.

Go with the flow

We had realized that we had been walking with the refactoring dependencies, i.e. we tried to refactor a part of the code that was depending on that another refactoring already had been done, which it hadn’t. If we could just walk with those dependencies, or prerequisites, until we reached a re-factoring that had no prerequisites, a leaf in the dependency graph, then we could just do that refactoring without any hassle. And by doing that, we would have fulfilled the prerequisites of another re-factoring that now had become a leaf, ready for execution. By doing so with all prerequisites, eventually our goal would be met!

The Mikado Graph and the Mikado Method

The Mikado Graph

When we presented this method at SDC2009, Laurent Bossavit suggested that this dependency graph and dependent refactorings had great similarities with how the Mikado Game is played. In order to get to “The Emperor”, you cannot just pick-up that stick. First you have to pick up all the sticks that in some way is above that stick. We thought it was an excellent observation and we now call it The Mikado Method and the dependency graph is called The Mikado Graph, as suggested by Laurent.

The Naive Approach

In our real-world case, we drew the Mikado Graph on a whiteboard, step by step. To do that, you naively start with the thing you want to achieve and draw that on your Mikado Graph, typically a business goal. Try to implement that change. If that goes all well, you are done. Check-in. Congratulations!

In most cases, however, you end up with compiler errors or tests that don’t run. Examine the errors and failed test and come up with measures that would have prevented those errors or test failures. This is often other refactorings in the application. Those measures become sub-goals to you business goal. Draw them on the graph as well, with arrows pointing from the business goal to the sub-goals. Revert the code to the previous working version.

Now, for each of the sub-goals repeat the process by naively trying to achieve them. Draw the solutions to the new issues as new sub-goals, revert the code, attack new sub-goals and so on. In the end, you can actually implement a leaf sub-goal while the application still works. Great! You just got one step closer to achieve your business goal.

By doing the refactorings from the leaves and in the opposite direction of the dependency arrows, you will eventually achieve your set out business goal.