Now that I have finally done my Scotch on the Rocks 2013 presentation, I feel it’s about time that I blogged about this method that I have been using for the last year or so.

What is the Mikado Method?

Simply put it’s a way to work on morphing a system to a better state in a structured away. It’s called the Mikado Method because it’s very similar to the name of the same name (also called pickup sticks) Where the Mikado (the goal) is what you’re after and you need to slowly remove all the other sticks that are in the way.

How does this relate to software development, we have all tried to implement a change to our software and we find it’s not as easy as we first thought, and the system breaks and as we keep trying to fix this errors there doesn’t seem to be an end to it.  The reason for this is that we as developers miss one key point, you can’t fix a system that doesn’t work fundamentally.

There are 4 key points to the Mikado Method:

  • Set a Goal
  • Experiment
  • Visualize
  • Undo

Set a Goal

If you’re going to make a change to your system you need to write down what you’re goal is and we do this on a piece of plain paper or on a whiteboard and we circle it twice to remind us that it’s the goal of what we’re doing.

Experiment

Just dive in and try to make the change you want to do, you will find that you have broken code but you note this on your Mikado graph.

Visualize

Using the Mikado graph by writing these things down it helps keep track of what we’re working on especially if you’re working on a large legacy system; it’s better on paper then in your head. Every time you find a something that breaks as you implement a change you make a note of it

Undo

The most unintuitive thing is the biggest key thing. UNDO once you have experimented and found something else is broken revert the code, it’s broken it won’t work. If you have a spent a while on some code and don’t want to lose the code you can patch it out so you can apply it later, but your need to REVERT the change out ensure you’ve put the item on your graph and then experiment again to fix this issue and if you find more again revert and note the error on your Mikado graph and then attempt to fix this error and continue you on.

Conclusion

For me the Mikado method means that you can morph an active system slowly and still have the system releasable. You’re improving the system slowly but surely and adding benefits to your customer / business although it may feel wrong reverting code you are always learning how the system works, especially if it’s something you’ve inherited from other developers.

My presentation is located here: http://nud.gr/mikadoSOTR
Also there is a booking in Manning prerelease, which you can grab from here: http://manning.com/ellnestam/
Also there is a video from Lean Agile Scotland in September 2012: Kev McCabe – Mikado Method – Making Code Changes Less of an Impact

 

2 Responses to The Mikado Method

  1. Colin Kershaw says:

    These techniques seem very similar to what Michael Feathers documents in Working Effectively With Legacy Code, especially Chapters 16 and 17. Additional techniques and ideas may be found in his book.

  2. Philip Oakley says:

    Kev,

    The link to your presentation (http://nud.gr/mikadoSOTR) has died.

    I enjoyed the 2012 Lean Agile Scotland video & slides. It was informative. (Linked from Clarke Ching’s blog)

    One question is do you have any support techniques to formally record the dependencies discovered during the naive solution / revert stage such that later solutions can link back to them in a testable manner?

    I’m thinking here of, say, using a git branch (or branches to get the dependency tree effect) to hold some form of test script(s) that helps automate the dependency checking later (i.e. the dependency is linked back into the new mainline solution). This could improve the dependency checking.

    Given the capabilities of some DVCS systems it did feel that one could extract some features of the hand written notes and diagrams (which are a good thing!) into some form of TDD.

    Any thoughts would be of interest.

    regards

    Philip Oakley

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>