Start Paying your Technical Debt – The Mikado Method

[at we will put more information on the Mikado Method]

A couple of years ago, Ola Ellnestam and I was working on a project where the code was a big ball of mud, or at least well on the way there. Global variables and singletons all across the code base, circular dependencies, deep and fragile inheritance hierarchies etc. The Technical Debt was everywhere.


All of a sudden we were supposed to deliver to a new client and the interest on our loan went through the roof. The reptile response from several developers on the team was to copy most parts of the code base to a new project and modify the code there. This would double our debt, but decrease the interest temporarily, until the next client would drop in. We fought with all we got to avoid doubling our debt and in the end we had convinced everybody that we could re-factor the code-base, just give us a week or two…


Elastic-, plastic- and fracture characteristics of code

I recently had a post about technical debt, and Jelena made a very insightful comment that it was like elastic, plastic and fracture characteristics of materials like steel. I started to comment on the comment, but eventually I thought it deserved its own post. More

User-Guide-Driven Development

In my work with Bumblebee I use an approach I call “User-Guide-Driven Development”, or UGDD for short. The mechanics of UGDD is similar to that of Test-Driven Development (TDD), but before I write the test for a feature, I write a snippet of the user guide describing the feature I am about to implement. More

Refactor towards abstraction

I have been in discussions about how far to refactor a lot of times. “Until duplication is removed”, is a common position, and sure, that is fine.


Refactoring organizations – refactoring code

Today I was struck by the similarities between rewriting code (as opposed to refactoring it) and how many companies reorganize.

When I was a young programmer and the code I had written was a mess I thought that if I just got the chance to rewrite everything it would then work better. Out with the old, and start on a blank sheet.


Unit tests, acceptance tests and documentation – trying to strike the optimal balance

Lately I’ve been coding away on my hobby project Bumblebee. Bumblebee is about integrating your documentation into you test cases and get human-readable documents from it.


Exiting TDDoc, entering Bumblebee

A couple of years ago I got extremely annoyed when I had to write a word document with basically a copy of the code I had written.

There was to be a lot of copy’n’pasted code, runtime values etc and the knowledge that I would have to go through everything again a couple of weeks later because of smaller changes in the code.

I of course argued that there were a lot of test cases describing the system, but the client wouldn’t accept that for documentation.

Since most of the information that would go in that document was available in the test cases, I felt that there had to be a way to get that data into something more human friendly.


Restarts as a strategic tool for better software

During the years when I started to learn agile development, especially TDD and good OO, I had the fortune to work as a consultant for a company that ran a massive number of small projects, each lasting for approximately 3 months. This was exactly the amount of time I needed to learn something new, apply it, and discover the limitations of it.

At the end of each project I realized there was a much better way of doing things, and the effort to rewrite the code probably would have eaten me alive. But hey, no problem, I’ll be on a new project next week, with a fresh code base to apply my new findings at.

At that time the recurring project restarts actually was a good strategy to improve the average code quality! If I would have had to keep on working with the same code base I would never have been able to incorporate that much new technology and knowledge in the code base, and I would never have learned that much about what makes code good.

Later on I also learned refactoring, but I doubt I would appreciate it as much if I hadn’t learned about good code first. I think this is one of the great limitations of refactorings, it requires a lot of experience to know in what direction to go.

By allowing people and projects to restart you can make people raise their sight to take a new direction, to get a new vision of what it will be like there, to learn and incorporate their experiences in the new. Granted, most agile processes have retrospectives, but sometimes they are not enough a kick-in-the-butt to start off something new.

If it is hard to introduce refactoring in order to improve the code base, or when retrospectives don’t seem to do it either; try a fresh start iteration where you can dream a little! If you realize it’s not leading anywhere, just keep on working with the old code base. In the long run you will probably gain more from the new perspectives than the lost iteration cost.


Get every new post delivered to your Inbox.