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

Daniel Brolund

+ 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 Daniel Brolund


We hope you'll find the book and it's ideas useful!

Thank you all, and please keep posting questions and we'll try to keep answering them.

You can also use the Manning forum at


Hi Sunderam,

I take the liberty of answering your question. :-)

The Mikado Method is primarily to make code changes to existing systems, and it shines in situations where you have a lot of entangled dependencies to keep track of. We've mostly used it for just that when implementing new features, or just changed the way things work, as in refactorings/restructurings. This is what the book is about.

We have also used a Mikado-like dependency graph to keep track of things needed for e.g. deliveries, but this is not in the book.

A friend and former colleague of ours has used it for organizational change. This is not in the book either.

We strongly believe that dependency graphs are good for making models of the world that help us understand how things are connected and to act upon that information. We encourage you to try the next time you have a problem. Software development, deliveries, refurnishing a room, or something completely different. :-)
Hi Karina,

Writing stories, or collecting information of what needs to be done from a business perspective, is a huge topic and beyond the scope of this book. Effect mapping is one way to do that, and it does share some ideas with the Mikado Method. See
for a quick overview.

If you need to change the story (or Goal) you have to look at the impact of the change on your code base. In general, you can probably just assume the current state as a new starting position for the changed story. If you want or need to, and can, revert your partially implemented story you can do that.

If that happens often, maybe you should not try to find a rock solid process to handle it, but rather see if you can change how you work, to avoid it altogether? This is just a thought, and has little to do with the Mikado Method. :-)

We have not read that book, probably because we haven't worked with C++. :-)

As Ola has stated in one of the threads here, the Mikado Method helps you find what is stopping you and keep track of your change path (graph) to achieve a goal. The direction in which to take your codebase is up to you, speaking strictly Mikado Method.

But, we thought it would be evil to just leave our readers with that ;-) so in part II of the book, we do have a chapter where we talk about the things that has helped us immensely when restructuring (OO) code: Design principles. Low coupling, high cohesion, SOLID and the package principles, DRY, and more.

Looking at for instance SOLID and the packaging principles, they are what usually makes us avoid changes to ripple through the code base, making it possible for a large system to compile fast. We don't go into great detail, but we explain the basics and some smaller examples of what it might look like, in packages and in Mikado Graphs.

If Lakos takes the code in some other direction, you can use that direction when deciding how to resolve what is stopping you.

I hope that was some sort of comment on the matter. :-)
Hi Ernest,

The purpose of the Mikado Graph is to represent the dependencies of just the things you need to change. This is usually not the same as the dependencies in the code base, although the dependencies in the code base will of course influence the order in which you need to do things.

So the answer is no, it's not a good starting point for a Mikado Graph, but it is a good source of information about your system. :-)