Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Ola Ellnestam

+ Follow
since May 21, 2013
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ola Ellnestam

Hi Margaret,

The Method does not really care whether the prerequisites to a change are in the code or the data. It does however explicitly say that you should add /any/ prerequisite to a proposed change to your graph.

When it comes to data(base) restructuring the Method itself is agnostic but we believe that fast feedback from automated tests helps in those cases. And if you are restructuring data you probably want the tests to be on 'a different level' than the change itself.

Lokesh --

Using The Mikado Method is great way to surface dependencies and it doesn't really matter if they are structural dependencies in code or things you need to take care of before something else can be done. I.e what needs to happen before a new feature is complete.

If you use it to 'drive' new features your graph might be a bit more exploratory, change more often and contain some guesswork, but not necessarily so. You can actually be very strict when you develop new features and do a lot of reverting. But usually the code is a bit more forgiving when you add to it.

So the short answer is; Yes, it can be used for new features as well as restructuring and regaining control of a messy code base.


Ananth Chellathurai wrote:I am sorry for the dumb question, but what does Mikado method provides over regular agile processes like scrum?

Ananth --

The Mikado Method fits inside other processes, e.g Scrum, and you can use it several times within one sprint for example. In other words, you use it in conjunction with other process.

As a side note: You can use the Mikado Method for restructuring software but you can use it to guide development of new features as well. I do that a lot too.

It offers several benefits, one of the more compelling from a team process perspective is the visual 'map' you get. That can be used to sync teams over time and space.

Hi Qunfeng,

Any tool that can draw a graph will do.

Our favorite tools are markers and whiteboard/paper. Especially a whiteboard that the whole team can see.

Thanks David,

I'm glad to hear that you're already doing a lot of this stuff.

Working with brownfield development is not like anything else but I somehow find it very pleasing anyway. Especially when I can remove a lot of code. :-D


Hi Junilu,

a) The method itself /only/ suggests that you don't do any additional changes if the code is broken, i.e doesn't compile, breaks tests or just isn't functioning the way it should. And I guess this is where 'the rock and a hard place' comes in. It's the "I can't add a test safely, and I can't change code unless I have a way to test things". The crux of the questions is really how to balance safe changes and fast enough progress. First, we need to balance between the need for a change to be absolutely safe and secondly. Secondly how long can we wait before we know the effect of our change.

So, if it dictates anything I would say the extensive use of _reverting to a know state_ and _trying to do the smallest change you can get away with_.

b) What I believe is the biggest 'add-on' to Michael's work is the systematized use of what he calls 'scratch refactorings'. Where a 'scratch refactoring' is a change you do, then restore the code, only to learn about the system.

The Mikado Method makes extensive use of this and encourages you to:
- Try a change
- See what happens
- Make a not of one possible solution to that on a piece of paper
- ... and then revert the code to it's initial state

Then you repeat the process until you can actually achieve something.

It adds to Michael's work and if you have read WELC (which I encourage all to do), you will see that the Mikado Method is a natural extension to his great book.


David Sachdev wrote:

Ivano Pagano wrote:Hello to the book authors.
If I understand it well, when I start working on a specific goal and try to reach it, I'm not supposed to know about the whole system design if it's not directly connected to the goal at hand. But shouldn't I know about the whole picture to avoid that each developer creates ad-hoc solutions for single features, eventually creating a system that, though being fully functional, becomes ever more unmanageable.
Doesn't each successive goal become more hard to solve? How does the method handle system decomposition, components decoupling and similar issues without having a more holistic approach?[/list]

Thank you so much for any clarification

I too am curious to know about how much of the whole picture you are seeing (or not) with this approach. I'll admit I'm one of those that likes to spend a little extra time looking at the big picture before diving in. And it may take me a bit longer to get started on a dev project, but I think I tent to get it finished correctly faster because of it.

Ivano and David,

We have found that analyzing code and especially the steps of a code change can be very frustrating but also time consuming. No matter how long you analyze the code there's almost always something that you miss.

The Mikado Method doesn't help you design, decompose or decouple code in itself, it helps you surface difficult to see dependencies by systematically and empirically trying to achieve a goal and changing code. That is you try things and then revert. It doesn't tell you exactly how to solve the dependencies and design flaws, it just points your eyes towards the issues.

It does a great job however in helping you uncover the restructuring map and reducing the cognitive load on you brain.

Also, If you are in a team setting, which I suppose most of us are, then showing a restructuring map (i.e the Mikado Graph) to another team member makes problems/solutions easier to discuss and identify.

In short; the method doesn't help with design, that you have to learn elsewhere. It points to things that needs to be taken care of before you reach your goal and its prerequisites and their prerequisites and so on.


Hi Rogerio,

The name of the method comes from it's resemblance to the Pick Up Sticks Game, which is sometimes called Mikado in Europe and mostly just pick-up-sticks in the U.S.

Mikado roughly translates to 'Emperor (of Japan)' and is also the highest scoring stick in the game. We think the game is a great metaphor for large restructurings.

Hi Mohamed,

It is a low ceremony process that surfaces hard to find dependencies in a code base. I use it when I restructure big and small chunks of code that I either can't fit in my head or can't finish in one sitting. You can use it in an Agile context or pretty much within any other software development process. It works best though with short feedback loops.

Thank you,

I am honored to be invited and I will do my best to answer you questions as quick as I can.

As I am located in Sweden I will normally be checking in here forum around this time. (~21.00 Central European Time)