Integrating Mikado Method and Chaos Engineering to Refactor Systems

Have you ever tried your hand at refactoring a legacy software system? If you have it, likely you found that: you edited more files than you expected; you reduced the size of a code block, but you weren’t able to get it compiles, and that many factors contributed to the unreliability of the system.

When you have to refactor a system, different parts can fail in varied and unexpected ways. Architecture patterns could not work well in some situations, and many tradeoffs must be made about which parts to refactor first.

Mikado Method is a structured strategy to make significant changes to complex and large systems. Rather than getting caught up in the complexity of moving parts, analyzing the entire system in one large chunk, the Mikado Method lets you handle complex code a bit like you’d move furniture around in your home, one piece at a time [1].

You need to do it one step at a time.

The key to the Mikado Method is removing the fewest obstacles at the time that you achieve real results, without breaking the code. Considering that Mikado Method is agnostic to the development approach used and works very well together with the iterative and feedback-intense approaches …

I think that Mikado Method could make a good fit with Chaos Engineering.

The Mikado Method helps to divide almost any problem into small and conquerable pieces. The four basic concepts of the Mikado Method could be extended with a step before to undo, that generates a chaos attack:

• Set a goal [Mikado]: it is about that to achieve. The goal represents a starting point for the change and determines if the method has achieved success or not.
• Experiment [Mikado and Chaos]: it is a procedure for discovering or establishing the validity of a hypothesis. It allows to verify that the changes apply to the code.
• Visualization [Mikado]: it is about writing down the goal and the prerequisites necessary to achieve it. A graph is commonly used here.
• Attack [Chaos]: it is about to break things on purpose to learn how to build resilience and reliability in the system. Some experiments include “packet-loss attacks” or “latency attacks”
• Undo [Mikado]: it is about to undo the changes if the experiment for implementing a goal has broken the system. After visualization of what should be changed in the system to avoid that outcome.

I hope that includes Chaos Engineering in the Mikado method can reduce the chaos while you are refactoring your system.

[1] Ellnestam Ola and Brolund Daniel. The Mikado Method. Manning.