Mikado: breaking out of Catch 22

[Junilu Lacar]

Ola and Daniel,

First of all, thank you in advance for spending time with us this week to explain the subject of your upcoming book.

I got the MEAP notice about your book last week and the title piqued my interest enough to actually take a look at its MEAP page. It sounded very promising and I actually went ahead and took advantage of the discounted MEAP and ebook deal. I was hoping to start reading the available chapters soon and start sending in feedback but since you're here this week, that's even better!

Brownfield development is my bread and butter. It's also one of my greatest sources of stress and frustration. The most difficult and challenging brownfield development is when you have legacy code (in the Michael Feathers sense: no unit tests) that is not only convoluted and incoherent but highly coupled as well. This makes it difficult to nearly impossible to write unit tests that make it safe to refactor. Michael Feathers' book "Working Effectively with Legacy Code" has been a great help to me over the years in creating enough wriggle room to start the long and arduous task of refactoring really bad legacy code.

I actually have two questions for you:

Does Mikado have specific recommendations for breaking out of the "between a rock and a hard place" situation you often find yourself in with legacy code?

What does Mikado add to Michael's strategies, if anything, and how is Mikado different, if at all?

Thanks!

[Ola Ellnestam]

Hi Junilu,

a) The method itself /only/ suggests that you don't do any additional changes if the code is broken, i.e doesn't compile, breaks tests or just isn't functioning the way it should. And I guess this is where 'the rock and a hard place' comes in. It's the "I can't add a test safely, and I can't change code unless I have a way to test things". The crux of the questions is really how to balance safe changes and fast enough progress. First, we need to balance between the need for a change to be absolutely safe and secondly. Secondly how long can we wait before we know the effect of our change.

So, if it dictates anything I would say the extensive use of _reverting to a know state_ and _trying to do the smallest change you can get away with_.

b) What I believe is the biggest 'add-on' to Michael's work is the systematized use of what he calls 'scratch refactorings'. Where a 'scratch refactoring' is a change you do, then restore the code, only to learn about the system.

The Mikado Method makes extensive use of this and encourages you to:
- Try a change
- See what happens
- Make a not of one possible solution to that on a piece of paper
- ... and then revert the code to it's initial state

Then you repeat the process until you can actually achieve something.

It adds to Michael's work and if you have read WELC (which I encourage all to do), you will see that the Mikado Method is a natural extension to his great book.

//Ola