The Mikado Method: A Systematic Approach To Restructuring Software

1. [...] Ola can you just briefly explain for those who don’t know what the Mikado Method is and what its purpose in life is?

Mark's full question: Hello my name is Mark Collins-Cape and I’m here at QCon London 2014 with Ola Ellnestam who is a coach and mentor for both business and technical teams and loves to combine technology, people and business ideas together and that is why he really finds Software Development interesting. Ola is also one of the creators of the Mikado Method which is being presented at this conference and you can find a link to it on the website, however just to start with, Ola can you just briefly explain for those who don’t know what the Mikado Method is and what its purpose in life is?

It’s a structured way to do changes in software, is especially you can do it for pretty much any structural change but especially we came up with the idea when we were up against a big change in a software project that we were doing and we were trying to move classes around and change software: not what you call refactoring, but more of a restructuring, but within that restructuring there is also refactoring and then we found out that we needed some support because this sort of restructuring was too big to fit in a day in one sitting, so that refactoring restructuring went on for three weeks or even more than that, so then we came up with the idea of how to systematically approach large scale changes, so that basically in a nutshell what it is.

Mark: Ok, I mean does it have specific steps for example when you get brittle programs where you change something and seemingly something else should be unrelated, suddenly breaks and I saw of presentation and that seems to be path of the…

I think that is the sort of a nature of software, well you change something and your intent was not to change this part over here that is sort of exploded, but with the Mikado Method you approach it more systematically and you have a clear goal, have decided upon what you want to achieve, and then you try to achieve that in a very direct, naive way, you try to do the change and then you see something breaks and then you learn from that, that if you take that information, so if you are trying to move a class from one package to another and then you see ok, so this depends on that and ok, I can’t do that and then you roll it back because you want to work with the software that works all the time, so you don’t build something a change upon a change, upon a change, upon a change when you are in a broken state.

2. If you are rolling back, is that means you are using the SourceCode control?

Yes, you have to, otherwise if you change more than a couple of files you can’t use like with word with the control+Z you can do that, you have to have Source Control.

3. It’s like a local copy of the software, is not check in into the production?

No, not unless it’s working, so you have to have like a local branch and then with the Mikado Method you can check in because you do only small changes and with that small change when it works you check it in and then you try some small change again.

4. Suppose you try to change something and you hear, you change it and then you find another problem cause of that change and you try to fix that and you find another problem and then you’ve might back out of several steps like that?

Yes, you have to back out of that, that was the major learning that we did, Daniel and me, we were at the project and learning and we sort of discovered the method that if you build a change upon a change upon a change you get a very brittle situation where you can’t know if something is working, if your changes … if you are moving towards a better future or worse, so you have to back out.

5. Once you’d backed out, you still got the original problem you are trying to solve what you do, you attack it in another way?

So when you try to do a change and you come across an error or some kind a compiler error or a test that isn’t running, you write that down on a piece of paper or a whiteboard and then you roll back, and then you take the information that we have and then you try to fix the prerequisite of that change, so what can I do in order for this not to break. And then you try that and if that brakes something, you put down another prerequisite on a piece of paper and you keep on doing that until you hit something that you can do. And if you are very systematic about it as the method suggests that you should be, you get a sort of dependency graph; changes that depend on other changes and we call that the Mikado Graph. It can also be called the Restructuring Map or Refactoring map.

6. Sounds interesting actually, so what success have you had with this method and explain it to the other people, have other people take it on and?

Some people, there are real two camps, one camp it says like: “Oh, this is how you do refactoring, this is so obvious, this is how I do Software Development” and then you have the other camp: “Oh, this was a very non-intuitive approach, it must have taking you years to come up with it”, it’s like “yeah, that’s what it took!”, but you have this two sort of not opposite but, two reactions like: ”Yes, this is common sense” and “wow this is new”.

7. It’s prerequisite to have some sort of the Unit Test there?

No, it’s not a prerequisite, but you have to have one way or the other to find out if you are breaking stuff, so if you don’t have a Unit Test, you’d better have maybe a compiler/statically typed language. If you don’t have a statically typed language and don’t have Unit Tests, you better have forgiving users or a way to roll back fast.

8. Have you ever look to anything like Michael Feathers book Working with Legacy Code is there any similarities or overlap with that?

Yes, I don’t know if there is an overlap, but if you in combination with each other, the Mikado Method and Michael Feathers techniques, I think we have looked a lot on Michael Feathers stuff and also Clean Code and that Michael Feathers stuff is about finding that seam, finding that place where you can change something, and with the Mikado Method you really structure your change and then you use Michael Feathers techniques, so his techniques is more of a prerequisite to the Mikado Method than J Units Tests or Unit Tests are. If you know Michael Feathers stuff you become much better at using the Mikado Method.

Mark: So they complement you?

I’d say they complement, they complement each other really well.

9. One thing we could say, it would be nice if the world will be a better place if we didn’t actually have such brittle software; it tends to happen. Why did it happen, is it lack of skilled programming or what is your experience of that?

I’d say that brittle software comes from sometimes lack of experience and sometimes more often change in that unforeseen change. And I say that change can come from very different areas, it can come from Technical Requirements are changing, like a Third Party API, Google changes its API and in unforeseen way and then all of sudden you have this massive amount of technical data or you can have a new functional requirement or there is a new law in banking or finance, means that the code that you had yesterday look really, really good, but today you have to fit something new into it and it looks really, really bad.

10. That is the heart of what refactoring is about, making that sort of, you got a new functional requirement and then you need to make a change so you have to somehow restructure your code to accommodate there. Is pressure of the time that makes people not do so well?

I would say pressure of time and you are always under constant pressure to deliver new features or some new thing that is working, and it takes so little to pressure a developer to do a bit more of a sloppy job. You just have to say: “Oh, can’t we release that a bit sooner?” and that software developer starts think of cutting corners, but I’d say it’s more efficient to cut scope, than to cut corners.

Mark: Sounds like a good idea. I mean having use your method on large software systems, I mean are there any sort of rules or intuitions you’ve had about what could be done better in the first place, I mean you sort of things that comes out the typical problems and what not

In the later years I’ve started to modularize my software more, put them into smaller, smaller packages, so they can have a very contained specialized area. I use to, a couple of years ago, my sort of projects or modules were bigger, but now try to make them smaller which means that I have to juggle more Dependencies but I do get, it’s easier to test things when they are smaller, when they are contained.

11. You mention Modularity and Dependencies, have you looked to Robert Martin’s work on principles of Modularity, open-closed principle, common closure principle, common reuse principle and so on, do they sort of resonate with your experience with Mikado?

Yes, the Bob Martin’s work and the SOLID Principles, the Open-Close Principle which is a part of SOLID and also the Package Principles, all of them if you know them by heart you are very much helped when you restructure a software, but it’s one thing to know about the principle and then to put it into practice. It’s so hard to even though I know about the principle and I try to structure my software in a certain way, change comes about and that change makes the code look crappy instantaneously, even though I thought I had a really great model and well software it’s just a model of the sort of supporting the reality in a way. So I’d say yes, well also what Bob Martin is doing when has been doing with SOLID and all the Package Principles a very good combination with the Mikado Method.

Mark: Ok, Ola thank you very much for talking with me here, it’s been enjoyable and people can see your presentation on Mikado Method on the website here, as it be recorded, and it’s Goodbye from us!

Thanks you very much!