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.


If-else or DecisionMaker?

On the testdrivendevelopment list there has been a discussion lately about what a testable language should look like.

I threw in a thing I’ve been thinking about for a long time: make a language without if-else/switch-case’s. They hide bugs, make you miss states, make the code unreadable, and they make the testing complexity explode.


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.


Previous Older Entries