I read the book (which is only 200 pages, a lot skimmable, and free online even (edit: used to be, now parts on the manning site are garbled)) and liked it. Pre

I read the book (which is only 200 pages, a lot skimmable, and free online even (edit: used to be, now parts on the manning site are garbled)) and liked it. Presented it to some coworkers once, and described how I used the method pretty successfully for a few actual work items. Because the work environment used Perforce, not everything was done as micro commits, but still. One task was small, it was to delete a secret token from a hardcoded XML config file and instead have it be consumed by calling out to a new secrets server some other team had setup. Nodes were things like "Read the doc for this new service", "Unblock the MVN issue preventing setting it up locally", "Set it up locally", "Store the token locally", "Store the token to the production cluster", "Identify all consumer(s) of the token", "Update the consumers to pull from the server", "Remove the token from the XML". Another slightly larger task was to refactor/fix a migration framework someone who had left the company wrote to migrate version-by-version doing all components at each version at once, instead of component-by-component doing all versions for just it at once. Without Mikado it probably would have been one giant commit, with Mikado it was 3 with everything working at each step. (If we used git probably could have been more.) And the migration bugs basically went away after that, so that was nice. The method is something I think about when things start to feel uncertain or hairy, but I try to avoid such situations, so I haven't used the method very often in the last few years. Especially the formal version. Informally, for my solo work (it works outside of coding too) it's more like a more structured TODO list -- it becomes a TODO graph, with an obvious do-this-next item (one of the leaf nodes with no prerequisites). It can help in planning and breaking things down as well, even if it's not used for the implementation work itself. A dependency graph alone is useful for a lot of stuff. The biggest objection is always the revert step. It's similar to TDD's red-green-refactor idea. If your tests start breaking during a refactor, you didn't correctly refactor, so rollback and try again. They should only break when you write them to fail in the red stage. I don't particularly like TDD, and don't practice it, but the idea of going back to a known-working state in the face of issues is really vital rather than trying to charge forward. Yes, in a lot of trivial cases the blocker isn't worth a node in your graph and you can get away with plowing through and fixing the red squigglies in the IDE one by one and be fine, but you should resist the temptation if you're giving the method a fair go and if past experience doesn't exactly support your hubris. In practice reverting usually isn't a big deal. The changes you're making at any time tend to be pretty small, undoing them because you learn it's not time to make them yet isn't usually a great loss. And when you come back to it after resolving the prerequisites, doing it again doesn't take much time, because every step is supposed to be pretty simple, and you already did something like it before. (You can of course save more complicated bits off in a scratch file or local branch to refer back to later, just that it's more the exception.) Writing the code also isn't necessarily the greatest part of overall development time. Remove one unnecessary meeting and you buy yourself time to throw away and redo quite a number of changes. And the learning of the whole system you'll get is probably more valuable too, and is reinforced when you redo things a bit differently again after resolving prerequisites. Scratch work to throw away is part of work, anyway. Like, when I'm learning a new codebase, often I make edits to it that inline a bunch of stuff because so many codebases are messes of function calls going all over the place (often for good reason revealed later) and there's only so much jumping around my brain can handle before I start losing the overall context or struggling with the debugger's limitations. I undo it all later, but the learning part is what's valuable long term. Sometimes you need to explore options. Some wisdom from Carmack: "Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren’t sure which way to do something, do it both ways and see which works better.” (https://slashdot.org/comments.pl?sid=25551&cid=2774808 https://slashdot.org/comments.pl?sid=25551&cid=2774808) Also http://sevangelatos.com/john-carmack-on-parallel-implementations/ http://sevangelatos.com/john-carmack-on-parallel-implementat...