File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Agile and Other Processes and the fly likes Mikado: breaking out of Catch 22 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Mikado: breaking out of Catch 22 " Watch "Mikado: breaking out of Catch 22 " New topic

Mikado: breaking out of Catch 22

Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

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!

    Junilu - [How to Ask Questions] [How to Answer Questions]
    Ola Ellnestam

    Joined: May 21, 2013
    Posts: 10
    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.


    I agree. Here's the link:
    subject: Mikado: breaking out of Catch 22
    It's not a secret anymore!