What do you think?
Rate this book
The Mikado Method
Technical debt is best understood as the work remaining before job can be considered complete or, put more colorfully, the cost of kicking the can down the road. The Mikado Method is a process for surfacing the dependencies in a codebase, so that you can systematically eliminate technical debt and get things done.
It gets its name from a simple game commonly known as "pick-up sticks." You start with a jumbled pile of sticks. The goal is to remove the Mikado, or Emperor, stick without disturbing the others. Players carefully remove sticks one at a time, leaving the rest of the heap intact, slowly exposing the Mikado. The game is a great metaphor for eliminating technical debt—carefully extracting each intertwined dependency until you're able to successfully resolve the central issue and move on.
The Mikado Method is a book by the creators of this process. It describes a pragmatic, straightforward, and empirical method to plan and perform non-trivial technical improvements on an existing software system. The method has simple rules, but the applicability is vast. As you read, you'll practice a step-by-step system for identifying the scope and nature of your technical debt, mapping the key dependencies, and determining the safest way to approach the "Mikado"-your goal. A natural byproduct of this process is the Mikado Graph, a minimalistic, relevant, just-in-time roadmap and information radiator that reflects deep understanding of how your system works.
It gets its name from a simple game commonly known as "pick-up sticks." You start with a jumbled pile of sticks. The goal is to remove the Mikado, or Emperor, stick without disturbing the others. Players carefully remove sticks one at a time, leaving the rest of the heap intact, slowly exposing the Mikado. The game is a great metaphor for eliminating technical debt—carefully extracting each intertwined dependency until you're able to successfully resolve the central issue and move on.
The Mikado Method is a book by the creators of this process. It describes a pragmatic, straightforward, and empirical method to plan and perform non-trivial technical improvements on an existing software system. The method has simple rules, but the applicability is vast. As you read, you'll practice a step-by-step system for identifying the scope and nature of your technical debt, mapping the key dependencies, and determining the safest way to approach the "Mikado"-your goal. A natural byproduct of this process is the Mikado Graph, a minimalistic, relevant, just-in-time roadmap and information radiator that reflects deep understanding of how your system works.
245 pages, Paperback
First published January 1, 2014
18 people are currently reading
253 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 26 of 26 reviews
March 29, 2017
I really enjoyed this one.
It draws a metaphor between the process of longer refactoring and a Japanse stick game ("Mikado") and then makes a lot of good points about how you should approach it. I've done my share of larger refactorings and the two trickiest thing are (1) keeping everything organized and (2) maintaining a good strategy over time. There are a lot of little ideas that help a lot with those.
My favorite bit was "the graph" where they suggest incrementally building dependency graph of all the changes you need to do. To construct it, you attempt a small change – it either happens easily or you uncover that there are dependency changes you should do before it. In the latter case, you revert, update the dependency graph and repeat the process with one of the newly discovered changes. You repeat this until you have simple changes at the bottom of the graph. Now you have a good plan, as well as an artifact you can use to communicate strategy with other team members. I've tried it a couple of times and it's a really neat idea.
It draws a metaphor between the process of longer refactoring and a Japanse stick game ("Mikado") and then makes a lot of good points about how you should approach it. I've done my share of larger refactorings and the two trickiest thing are (1) keeping everything organized and (2) maintaining a good strategy over time. There are a lot of little ideas that help a lot with those.
My favorite bit was "the graph" where they suggest incrementally building dependency graph of all the changes you need to do. To construct it, you attempt a small change – it either happens easily or you uncover that there are dependency changes you should do before it. In the latter case, you revert, update the dependency graph and repeat the process with one of the newly discovered changes. You repeat this until you have simple changes at the bottom of the graph. Now you have a good plan, as well as an artifact you can use to communicate strategy with other team members. I've tried it a couple of times and it's a really neat idea.
April 18, 2015
Even though this was a short book, the core concept, the Mikado Method, was not substantial enough to fill it. There was a fair amount of repetition and much of the book was filled out with semi-related supplementary picture. I suspect this is one of those instances where something is really more fit for a series of blog posts but putting it in a book gives it legitimacy.
But I still give the book three stars because the Mikado method is a small but clever tool for modifying code that you don't know intimately -- so any non-trivial code written by anyone else or by yourself more than 3 months ago =).
The core idea is that instead of endlessly analyzing the code, you just start making the simplest changes you can to try to achieve your goal. As you make changes, things will fail, and you capture what you learn in a dependency graph. Then, and this is the key part, you revert everything you've done so far and start one one of the leaves of your growing graph. Although the book has more detail than this article, the article has enough information to use the method productively.
The power of this method lies in the fact that you always have a working system. You don't get into a tangle where a change should be simple, but then there's an error. But the fix for that should be simple, so you push ahead. And again and again until you hit up against something that isn't simple and your code is a non-compiling, test failing mess.
You can take or leave the book, but I definitely would encourage reading the article and trying the method next time you are working in complex or unknown territories.
But I still give the book three stars because the Mikado method is a small but clever tool for modifying code that you don't know intimately -- so any non-trivial code written by anyone else or by yourself more than 3 months ago =).
The core idea is that instead of endlessly analyzing the code, you just start making the simplest changes you can to try to achieve your goal. As you make changes, things will fail, and you capture what you learn in a dependency graph. Then, and this is the key part, you revert everything you've done so far and start one one of the leaves of your growing graph. Although the book has more detail than this article, the article has enough information to use the method productively.
The power of this method lies in the fact that you always have a working system. You don't get into a tangle where a change should be simple, but then there's an error. But the fix for that should be simple, so you push ahead. And again and again until you hit up against something that isn't simple and your code is a non-compiling, test failing mess.
You can take or leave the book, but I definitely would encourage reading the article and trying the method next time you are working in complex or unknown territories.
August 13, 2018
The book describes a method for gradually figuring out the scope of a software (re)design problem & safely morphing a codebase from state A to state B while keeping it in a working state. The mikado method itself is very simple and can be summarized in a few bullet points:
* Try to make the naive change
* List everything that breaks (compiler errors/failing tests) as prerequisites for this change
* Revert your changes
* Select one of the prerequisites as a new starting point
* Rinse & Repeat
The book further expands on this and many other software design principles: SOLID &package coupling & cohesion principles, nitty-gritty refactoring tips & tricks and ends with a very clear and useful appendix on technical debt: what causes it, how can you deal with various debt sources, ...
It touches on very contemporary topics: it highlights the benefits of mob programming, trunk-based development & continuous delivery. It also references a lot of other works if you want to dig deeper.
Though the method in itself wasn't enough to fill a 200 page book, I found the generous & hard-won advice from veterans in the field sprinkled troughout the entire text more than worth my time investment.
* Try to make the naive change
* List everything that breaks (compiler errors/failing tests) as prerequisites for this change
* Revert your changes
* Select one of the prerequisites as a new starting point
* Rinse & Repeat
The book further expands on this and many other software design principles: SOLID &package coupling & cohesion principles, nitty-gritty refactoring tips & tricks and ends with a very clear and useful appendix on technical debt: what causes it, how can you deal with various debt sources, ...
It touches on very contemporary topics: it highlights the benefits of mob programming, trunk-based development & continuous delivery. It also references a lot of other works if you want to dig deeper.
Though the method in itself wasn't enough to fill a 200 page book, I found the generous & hard-won advice from veterans in the field sprinkled troughout the entire text more than worth my time investment.
April 7, 2025
Very interesting textbook. One of my senior engineers recommended this to me.
I feel like I've always struggled getting introduced to complex code repositories and not only that, starting to implement code into them. If you're in that same boat, this book and method is great for you.
Basically, the Mikado Method is a way to make big changes to complex codebases without getting overwhelmed or destroying everything ( like me ). Instead of trying to plan everything step by step, you go ahead and implement your feature ( you will probably break something ). When you run the code, look at the errors and broken dependencies, but instead of fixing them, write them down. This will be your Mikado Graph. The root of the your Mikado Graph is what you want to accomplish, and the children will be the dependencies, and prerequisites for what needs to be changed to make your feature work. After that, UNDO your changes completely ( why?? ? ?? ? ). Chill. Now you know exactly what actually needs to be done first. Fix one prerequisite that you jotted down and try again. Over time, you build a graph of what needs to be changed and in what order. Each time you repeat this process, it gets cleaner and smoother until your original change can be introduced.
Does that make sense? Idk.
I feel like I've always struggled getting introduced to complex code repositories and not only that, starting to implement code into them. If you're in that same boat, this book and method is great for you.
Basically, the Mikado Method is a way to make big changes to complex codebases without getting overwhelmed or destroying everything ( like me ). Instead of trying to plan everything step by step, you go ahead and implement your feature ( you will probably break something ). When you run the code, look at the errors and broken dependencies, but instead of fixing them, write them down. This will be your Mikado Graph. The root of the your Mikado Graph is what you want to accomplish, and the children will be the dependencies, and prerequisites for what needs to be changed to make your feature work. After that, UNDO your changes completely ( why?? ? ?? ? ). Chill. Now you know exactly what actually needs to be done first. Fix one prerequisite that you jotted down and try again. Over time, you build a graph of what needs to be changed and in what order. Each time you repeat this process, it gets cleaner and smoother until your original change can be introduced.
Does that make sense? Idk.
June 26, 2016
Too long, too late :)
July 10, 2017
As other reviewers have said, this book would have been better as a long blog post, or a short blog series.
July 2, 2019
the mikado method is nice. but could fit in a much shorter article.
December 26, 2020
The Mikado Method itself is great, but having a full book dedicated to it makes it repetitive.
May 11, 2020
An incredibly simple yet powerful method to make changes in your software. The Mikado method does not try to replace refactoring, it gives you a tool to navigate the many additional changes you need to do to introduce that complex change in your system that does not fit in easily. With its 4 steps (set a goal, experiment, visualize and undo) you can minimize the mental load of that complex change and focus on finding all the dependencies that you need to do before you can make your change.
The biggest challenge you may have with this method is the undo step. What looks like loosing your work is in fact a productivity boost. Never again will you need to keep changing part after part to get back to a state where your software works. You try to make a change and if it does not work, you revert. But before you throw your changes away, you write down what you need to change to make this current change possible. You repeat that until you no longer run into obstacles and you can do the change without reverting it. From that point on you have uncovered all the hidden dependencies and you can start making the changes in the reverse order of their discovery. Instead of that enormous change you only make small, independent refactorings that are fast and without risk. You will be much faster than the other way around even when you need to revert a lot of times to create that map.
Sometimes great productivity boost come from simple adaptions of your workflow. This is definitely the case with the Mikado method.
The biggest challenge you may have with this method is the undo step. What looks like loosing your work is in fact a productivity boost. Never again will you need to keep changing part after part to get back to a state where your software works. You try to make a change and if it does not work, you revert. But before you throw your changes away, you write down what you need to change to make this current change possible. You repeat that until you no longer run into obstacles and you can do the change without reverting it. From that point on you have uncovered all the hidden dependencies and you can start making the changes in the reverse order of their discovery. Instead of that enormous change you only make small, independent refactorings that are fast and without risk. You will be much faster than the other way around even when you need to revert a lot of times to create that map.
Sometimes great productivity boost come from simple adaptions of your workflow. This is definitely the case with the Mikado method.
July 1, 2024
Great little book on a structured way of refactoting code. As someone with obsessive-compulsive personality disorder, I'm all in for recipes and algorithms for practical tips to do software development. The method makes sense but is somewhat surprising in the means and tactics used.
However, the book could be way shorter and to the point. Part 2 is a generic treatment of agile software development that is better served by other in-depth books. The appendices are actually are a part 3, and I can't for the life of my why thy aren't regular chapeters, or at least incorportated in the already short chapters. But parts 2 and 3 could actually be replaces by more examples, in different languages, in how the authors used the Mikado Method in real-life projects. I also miss a little bit of history and where the graph-form came from.
Still, you will learn practical tips for better programming.
However, the book could be way shorter and to the point. Part 2 is a generic treatment of agile software development that is better served by other in-depth books. The appendices are actually are a part 3, and I can't for the life of my why thy aren't regular chapeters, or at least incorportated in the already short chapters. But parts 2 and 3 could actually be replaces by more examples, in different languages, in how the authors used the Mikado Method in real-life projects. I also miss a little bit of history and where the graph-form came from.
Still, you will learn practical tips for better programming.
May 14, 2023
Un des livres autour de la thématique du refactoring et plus largement de la restructuration de code.
Mikado method donne une méthode pour bien ordonner des suites d’ actions aboutissant à un objectif sur le code (dont un refactoring complexe).
Le livre pourrait être beaucoup plus puissant en donnant significativement plus d’exemples car le gros du bouquin est assez théorique (et de la théorie que je n’ai pas trouvé super poussée et intéressante). Dommage car c’est un problème difficile en effet pas du tout abordé dans refactoring et refactoring to patterns qui se limite à des refactorings très particuliers plutôt que de donner une méthode « générique »
Mikado method donne une méthode pour bien ordonner des suites d’ actions aboutissant à un objectif sur le code (dont un refactoring complexe).
Le livre pourrait être beaucoup plus puissant en donnant significativement plus d’exemples car le gros du bouquin est assez théorique (et de la théorie que je n’ai pas trouvé super poussée et intéressante). Dommage car c’est un problème difficile en effet pas du tout abordé dans refactoring et refactoring to patterns qui se limite à des refactorings très particuliers plutôt que de donner une méthode « générique »
March 14, 2021
There is a point when you have enough experience as a software developer that this book becomes superfluous. Unfortunately I am at that point, I couldn't make it past Chapter 1.1.2.
October 13, 2023
I like the graph-Part a lot. The rest, not so much ...
June 4, 2024
Interesting idea, but the book has lots of filler, could have been a blog post.
February 12, 2014
(It's a review of the MEAP - early access - version. However, Manning claims that this version has all the chapters and won't differ significantly from the final version.)
No, no, no & no. I totally didn't like it.
First, there's no *method* in Mikado Method. It's just basic common-sense:
* if you refactor the code you don't know well, keep it stable (working) all the time, so it won't get out of control
* refactor gradually, if you follow the blind path, revert the changes
* all your actions should have a clear target (even if it's to be achieved in a mult-step way)
* if your refactoring requires several steps, make a drawing (by-hand) so you don't get lost
And THAT'S THE WHOLE METHOD (written with my own words). Seriously! Yea, do you recognize that sound? This is Cpt. Obvious calling.
That's not all - there are so many naive statements in this book ... It encourages you to keeping the legacy system working by executing the automated tests! Has ANYONE seen legacy system with automated tests? Seriously ... The other funny thing is when author tries to give an example of solving the technical debt in an "entangled" piece of code that takes about two pages of space. It's not even funny - it's like he describes something that has no connection with the real life.
Anything positive about this book:
* it's only about 240 pages, so you'll read it fast (well, it's still 240 pages about something that can be summarized in 3 tweets)
* there's was a oneliner from "Clean Code" cited
* the chapter about theory of technical debt was not abysmal
I really, really, really hate to put such negative reviews on public, but this is clearly the biggest waste of money on books I've made in at least a year. Beware.
No, no, no & no. I totally didn't like it.
First, there's no *method* in Mikado Method. It's just basic common-sense:
* if you refactor the code you don't know well, keep it stable (working) all the time, so it won't get out of control
* refactor gradually, if you follow the blind path, revert the changes
* all your actions should have a clear target (even if it's to be achieved in a mult-step way)
* if your refactoring requires several steps, make a drawing (by-hand) so you don't get lost
And THAT'S THE WHOLE METHOD (written with my own words). Seriously! Yea, do you recognize that sound? This is Cpt. Obvious calling.
That's not all - there are so many naive statements in this book ... It encourages you to keeping the legacy system working by executing the automated tests! Has ANYONE seen legacy system with automated tests? Seriously ... The other funny thing is when author tries to give an example of solving the technical debt in an "entangled" piece of code that takes about two pages of space. It's not even funny - it's like he describes something that has no connection with the real life.
Anything positive about this book:
* it's only about 240 pages, so you'll read it fast (well, it's still 240 pages about something that can be summarized in 3 tweets)
* there's was a oneliner from "Clean Code" cited
* the chapter about theory of technical debt was not abysmal
I really, really, really hate to put such negative reviews on public, but this is clearly the biggest waste of money on books I've made in at least a year. Beware.
June 19, 2016
I thought The Mikado Method had some good things to say. It provides some solid advice for refactoring code bases in a stable, predictable, and easy way.
I think I've loosely followed this general method for a while, but not in a way that I could have articulated—it was more intuition than anything. So reading this was valuable just for the ability to articulate a method. I may not always go through the steps of writing everything down, but I think as a general method this is very sound.
There were also lots of tidbits scattered throughout. I'll definitely be recommending this—especially to more junior engineers, who are more likely to struggle with refactoring in a manageable way.
I think I've loosely followed this general method for a while, but not in a way that I could have articulated—it was more intuition than anything. So reading this was valuable just for the ability to articulate a method. I may not always go through the steps of writing everything down, but I think as a general method this is very sound.
There were also lots of tidbits scattered throughout. I'll definitely be recommending this—especially to more junior engineers, who are more likely to struggle with refactoring in a manageable way.
October 20, 2013
I hate giving negative reviews. And I may be wrong because I'm judging based MEAP pre-print, but this book is quite a disappointment. Nothing is really wrong content-wise, but it's very watered down. Feels like college essay when you MUST make it no less then 20 pages.
Seasoned software developer will find very little useful there to justify time spent reading. And I think that novice developer can do better by reading Working Effectively with Legacy Code by Feather and Continuous Delivery by Humble and Farley.
Seasoned software developer will find very little useful there to justify time spent reading. And I think that novice developer can do better by reading Working Effectively with Legacy Code by Feather and Continuous Delivery by Humble and Farley.
January 27, 2019
This is a slim book, but the content is even slimmer ! Mikado is a fine tecnic to address the refactoring of legacy code. You should try it, also because it's a really simple technic. But because it's simple, there is simple not enough material to fill-up a book. And therefore, the authors spent a lot of effort to fill the space with low value writing. It shouldn't have been a book, simply a very good paper.
Ma note de lecture en Français ici
Ma note de lecture en Français ici
April 27, 2014
I looked the ideas presented in this book. the only real problem with the book it that it is about a 50 page topic stretched out to 200 by using a lot of tangentially related topics. The method they present is simple, which is good. However, I am not sure they had enough material for a book.
That said, I thought the appendix about technical debt was well done.
I would recommend the book for anyone who has or is taking over a "legacy codebase" (as defined by Michael Feathers).
That said, I thought the appendix about technical debt was well done.
I would recommend the book for anyone who has or is taking over a "legacy codebase" (as defined by Michael Feathers).
July 29, 2014
Whilst I like the visual graph and often common sense statements that make up the Mikado Method this book disappointed me. I think the technical debt appendices were some of the best content. Usage patterns of the method were nice but mainly common sense. I was just expecting something more I think....maybe the common sense in here is not as common as I think!!
June 10, 2014
The best part of this book is the first two appendices, on technical debt and setting the stage for code improvements. Overall the authors have many words of wisdom on working with code and working with other programmers. Well worth the read.
July 13, 2014
I don't know why Manning refuses to release a book that is only 75 pages.
This book doesn't deserve 250 pages!
And the authors have an attitude against dynamically typed languages.
This book doesn't deserve 250 pages!
And the authors have an attitude against dynamically typed languages.
May 28, 2016
Interesting approach, however hard to say more until further tests in practice.
October 13, 2016
A formalized method of the thought process while solving problems and refactoring. A couple of useful takeaways.
September 26, 2020
Too much words. Is kind of repetitive but worth reading to know the Mikado method.
March 3, 2014
The Kindle version full of typos to the extent that it was very distracting.
Displaying 1 - 26 of 26 reviews