You know that area of the code nobody wants to touch? It’s been sitting there forever, just doing it’s thing. It is a functioning shanty town of code. And you know, as everyone on the team knows, that there is no such thing as a simple change to this code. Because the “solution” is coupled in the strangest ways, code seemingly separate from the module you’re working on breaks when you make the most mundane of changes.
But today, you picked up a user story that, try as you might, you cannot figure out a way to implement without either digging into the internals of the shanty town or bolting another hovel onto the side. You can’t keep adding onto this mess. You’re going to have to roll up your sleeves and fix it. But how? One change breaks two other things, which when modified each break two more. You’re destined for a path of exponential brokenness that will take weeks to fix and when it’s all done, you have to make one huge commit.
Ugh.
Enter the Mikado Method.
The Mikado Method is a relatively simple means of approaching these exact problems. By probing the code, we learn where changes need to take place. We then start at the outer edges and work our way in. We can commit small changes that don’t break the system and iterate our way towards a solution. It might still take two weeks to implement this simple change, but we’ve derisked the entire process.
In this session, Doc shows an example of the Mikado Method in use and welcomes audience members to contribute both to the coding and the discussion.
