Session: Large-scale refactorings using the Mikado Method

Friday, 15:35 - 16:25
Track: Agile

The Mikado Method: Code almost always depend on other pieces of code, hence one change often requires another in an entangled web. When working with software, one usually has to perform a series of refactorings before making the core change to the software, be it to enable adding a new feature or just making a part of the code read better.

This works like the game Mikado (pick-up sticks), where you have to pick up lower scoring sticks in a certain order to reach the higher scoring Mikado stick.

You can build your map of changes using analysis. We would like to present a less demanding way to build the map: ‘The Naive Approach’:

1. You set up a goal for your change.
2. Naively implement that goal, as you would wish it to be.
3. Compilers, tests, analysis and common sense will then show you immediate problem areas with your naive solution.
4. Resolutions to those immediate problems are noted as prerequisites to the goal.
5. The current changes are reverted using e.g. a versioning system or undo.
6. The prerequisites are now new goals. Repeat 2)-6) for each goal until you find no prerequisites.
7. Continue perform changes that have no prerequisites. You will eventually have cleared the prerequisites of other changes that now can be performed. Repeat this step until done, or continue from 2) if you find new prerequisites.

This can be described as a depth-first recursion of refactoring dependencies.

A more extensive description can be found here http://bit.ly/bVa13.

Contents and time line: This session contains some theory, but focuses mostly on hands-on working with code.

Part 1: Tutorial (35 min)
* Introduction to the method and to refactorings (10 min)
* The presenters demonstrates the method on an example problem, using Eclipse and Java (15 min)
* Q&A (10 min)

Part 2: Dojo: Practice in pairs (55 min)
* Repeating the same problem in pairs. BRING YOUR LAPTOPS. (50 min)
* Q&A (5 min)

Prerequisites

Java, C# or any other OO-language

Expectations

Visualize technical debt to non technical persons and how to work your way out of messy code