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
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.
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.
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
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.
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