The Mikado Method - Working with established Systems

On this page I'd like to share with you the so called Mikado Method, named after the game Mikado. It can be used to work on established systems in a systematic way, limiting the danger of breaking it. The project site by the authors Ola Ellnestam and Daniel Brolund is, other good descriptions are:

Although introduced for software development (especially among the Agile methods), it could be also applied to tackle hardware systems, I think.

The Algorithm

At its bottom Mikado is a multistep, iterative algorithm. Its steps are graphed in parallel, thus, during application you have a nice overview about the activities, their progress and dependencies. Here are the steps:

  1. Define the thing you want to change and put it as a node in a tree graph. the original goal will be the root node.
  2. Try to implement the change in a naive, straightforward way, without putting much design and analysis.
  3. Check if it all still works. If so, commit your changes and tick off the changed node. Go to step 7
  4. If you encounter errors, try to fix these, again in a naive way.
  5. Create a new sub-node to the thing you just wanted to change, containing the bug-fix as a new prerequisite.
  6. Revert the changes.
  7. Go back to step 2 for (one of) the outermost node in the tree.

So what you do is to create a tree from the root node by adding prerequisites discovered by erratic behaviour. At the same time you try to prune the tree outside in to successively fulfill the prerequisites and finally the initial goal.

What you need somehow

In order for the algorithm to be applicable, some prerequisites must be met. As the method is designed for software development, it is usually easier to use it in this field. With hardware it is probably harder.

Revertable Steps - Versioning

Step 6 implies that all changes can be reverted. In software that's easy if you use a versioning system. If the existing code is not versioned you can usually use a local system like Git or Mercurial. They don't require any fancy setup for this purpose. They also lend themselves to be used in a more granular fashion than central systems, so they could be used in addition for the numeroues changes required in the process, if you fear it will clutter the central repository.

For Hardware it is not so easy and involves a lot more abstract thinking. One thing difficult to undo is throwing away or destroying things. In that case you could simply mark those objects to be thrown away (put a sticker, put into intermediate storage) and see if the simulated absence would cause problems in other steps or turns out to be unnecessary. If you need to destroy an object to analyse it further, I have no idea so far, how to solve it - maybe one can come up with a non destructive method of investigation.

System Checks - Testing

Steps 3 and 4 require the system to be testable. How would you know, if it works or not? Obvious errors are reported in implementation by the compiler. The program behaviour requires special software tests, as runtime problems tend to hide.

In general for hardware steps could be actually played through (in thought) before executing them. Tests in software should be written such, that they describe the requirements for a certain piece of software and at the same time document how to use it. Similarly, such scenarios could be envisaged for practical cases in hardware?


The goal:

You try to do that by starting the coffee machine. It reports errors: no water, no coffee beans. You add the obvious fixes as prerequisites to the tree:

Now you pick one of these outermost nodes and e.g. fill in water. You succeed in removing the water error, as it is automatically "implemented" in this example, you can tick it off:

When tackling the next node you realize, that there are no coffee beans around, so you add the prerequisite to obtain them:

You find some coffee beans in a cupboard and fill them in, but you realize it's the wrong sort. You add the prerequisite to verify the coffee bean sort, and revert by putting the beans back:

Now, lets assume you got lucky and find another pack of coffee beans and verify them right away. They are O.K. Successively you can proceed through the nodes and fulfill all the prerequisites. /!\ Note, that other errors could show up during that process (e.g. you spotted the right beans in a locked glass cabinet ...), which would make the tree grow a few more nodes. That's why you go step by step. So, finally we are back to our initial goal:

You again start the coffee machine, it indicates no further errors and produces a cup of coffee. You tick off your main goal (and of course the coffee pay list, by the way) end enjoy the result of your hard effort. By following the algorithm you managed to effect your change (make coffee) while not introducing any bugs in the system (like using the wrong coffee beans, which can greatly annoy some people).

Again, the example is simple and not very detailed. You can choose the degree of detail according to the complexity of the steps. Here it is maybe already overdone, as making a cup of coffee usually doesn't require that much documentation ;) . However, if the problem is more complex and several people are involved, a systematic, central plan like this can help enormously to organize the work and bring to light relations between the steps. Every participant can detail his or her current step as needed.

MikadoMethod (last edited 2015-06-03 12:10:56 by OliverSchaefer)