Mikado Method For Refactoring Legacy Software

Posted by Roopesh Shenoy on Feb 19, 2012

Sections

Development

Topics

Agile ,

Refactoring

Share |

RELATED Research

Daniel Brolund presented the Mikado method in a talk-cum-workshop here in Agile India 2012. This proposes a simple method for agile teams faced with poor legacy code, which needs to be refactored in pieces as and when new goals arrive.

Normally, when you want to make a simple change in a legacy application, often there are things that start blowing up around this change – compiler errors, failed acceptance tests (if there are acceptance tests!) etc. You fix these and more things blow up, and this continues till everything seems out of control and you just want to start over.

The Mikado method proposes a simple solution. For each change, once you find the dependencies that show errors once you make that change, create a graph that depicts these errors, along with what needs to be done to fix them proactively before actually making the change. Then you revert your change and start looking at one leaf in that graph. Fix that error, see if that causes more problems – if it does, repeat the process – continue drawing more leaves on the graph with details of what else needs to be changed, revert the entire code change, and start working on the leaf again.

At each point when you revert the code, you might feel that you are back at square one, but you are not – you actually have more information than when you started with. Also, you are always working with code that compiles (and passes tests!), rather than having a lot of code that is not compiling, so that makes it possible to use the IDE refactoring tools. Each time a leaf node problem is fixed and it doesn’t lead to more errors, the state can be checked in very easily and the leaf can be marked green; once all leaves from a node are green, you can start working on that node and so on till you finish the original change. This means code is checked in in small increments, and can directly be worked on in the main branch (rather than having a separate branch for this).

It may seem like the graph can get unwieldy and too big for changes in large applications, but Daniel says it’s not usually so – the size of the graph normally doesn’t vary directly in proportion with the code size. The main purpose of the graph is to remember clearly the goal started with, and scope oneself to working only towards that goal rather than trying to do too much at once.

Daniel demonstrated this with a simple Java application, which needed refactoring to support multiple customers. This was followed by a simple workshop where the participants did that as well. You can download most of the exercises from github. You can also download the ebook. You can also read an earlier post on InfoQ on large scale refactoring. 

RelatedVendorContent

Agile Maturity Model Applied to Building and Releasing Software

How ALM Supports Business Processes

Using ALM to Drive Business/IT Alignment

Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!