The Mikado Method is deal of the day today!!

The Mikado Method book at Manning is Deal of the Day today the 14th of May!

Use the code ‘dotd0514au’ (without the quotes) for 50% off at

The Mikado Method Book at Manning

I only write when I feel have something important to tell, and now I do.

Me and Ola has been working on our book about the Mikado Method for quite some time now. First as a free PDF, and now as an upcoming book at Manning: The Mikado Method

At the moment it is in the Manning Early Access Program, which means you can buy it and be a part of the process by sending in your thoughts and feedback. The new book is a thorough rework of what we had before, so hopefully you will find it worth it even if you read the PDF already.

We’ll post the most recent stuff about it at @mikadomethod on Twitter.

What is Software Architecture?

The other day I got a nice LinkedIn email from graduate student asking me if architecture can evolve from continuous refactoring. There were a couple of questions about where it worked and where it didn’t, and I started wondering what was really meant by “software architecture”. Well, at the bottom of the email was RUPs definition of software architecture:

“The set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those elements, the composition of these elements into progressively larger subsystems, the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.”

WTF? What does that mean? What are they trying to say? That architecture is everything? If architecture is the significant decisions, what are the insignificant decisions?


Technical debt

My preferred definition of technical debt is:

Technical debt is existing (technical) structures that stand in the way of making the next change. The interest is the cost of having to deal with those structures in your day-to-day work, and the down payment is the cost of making the structures apt for use.

Debt can be intentional in that you take shortcuts to meet an important deadline or to hit a market window. In this case you have an expected ROI for the loan you take, one that you hope will pay off more than the cost of later fixing the shortcuts taken.

Debt can also be the unintentional, and here it gets interesting. One type of debt is that which results from sloppiness, usually resulting in a messy code base. This type is not related to any kind of investment, hence there is no expected ROI, it is just like  a loan for consumption of drugs; it will destroy you (your code) and your economy if it doesn’t stop.

By the definition above, debt can also be the result of external events, sometimes out of your control. Your perfect system can suddenly become your largest debt if you go from one to several customers, the company strategy changes, the market changes or laws change.

Some people, among them Uncle Bob in this article, argues that messy code is not debt. I disagree, for the reasons above. I think Uncle Bob and others confuse debt that results from loans taken to make an investment, and debt resulting from neglect, lack of experience or incompetence. The cause is totally different, but you’re still in debt.

There is no reason to make a messy system, since there simply is no return on that investment. Accept debt only to take loans that enable you to make a sound investment.

You are a leader. Yes, you!

A couple of years ago I was attending the course “Secrets of Agile Teamwork – Beyond Technical Skills” by Esther Derby and Diana Larsen. It was a brilliant course, and so far, I have had more use of it than any other course I have attended or book I have read. In the special Esther-and-Diana-style (you must try it if you get the chance), we learned about communication, conflict, feedback, change and leadership. We also learned a lot about ourselves from reflecting over how we behaved in different situations. Highly recommended!

One section in the course was “Team Leadership Activities” and that would prove a real eye-opener to me. It is a great tool to view a team through, to understand what makes a team move forward towards their goal and how you can contribute.


Jambda 0.1

I just released Jambda on Github, a small project in which Johan Kullbom and Joakim Ohlrogge has taught me all I can absorb about functional programming. I have mostly contributed with documentation using my tool Bumblebee in order to learn the concepts. The code is mostly written by Johan.

Jambda is a small Java library with typesafe implementations of options, unions, curryable functions, and a bunch of sequence functionality, like map, fold and filter.

The result is also a rather interesting use of Java generics where we probably have pushed the generics implementation to the limit (I say “we” but mostly I mean Johan).

The documentation is available here. Check it out! Any feedback is welcome.

Pancake programming

About an hour ago I was again making pancakes while programming. 1 minute in the pan on each side for programming time, then 20 seconds of flipping our pouring in a new one as break or retrospective. This resembles the Pomodoro Technique, but at a much higher frequency.

I found the rhythm rather comfortable. I want to believe that in an uncertain environment short feedback cycles are more beneficial than longer, and I wasn’t quite sure where to go with the code at the time.

There could also be some primal resonance with the 1 min 20 sec period, but I haven’t done any research on that.

It could also be that I have a brain disorder, but I’ll ignore that possibility for now.

Getting HTML element screen position

In my struggle to make Bumblebee fit for documenting web sites using Selenium, I need to crop screen-shots to show only a certain element of a web page, e.g. a certain menu or a cell in a table, instead of showing the whole screen every time. In order to do so I need to know the position of an element relative to the screen.

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…


Speaking at SDC2009!

Together with Ola Ellnestam, I will host a session at the Scandinavian Developer Conference 2009: Start paying your technical debt! at 17.15 in the Development Process & Methodology track.

We will talk about how to get organized around paying back technical debt that requires several iterations of work, while still delivering value and without having a broken code base in the process.

Previous Older Entries


Get every new post delivered to your Inbox.