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

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.

Copy’n'paste?

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.

Physical visible workspace is just more robust!

Did you ever end up feeling crippled with yet another “agile” story management tool?

You get what you measure

Yesterday I watched Grand Designs on TV where a couple restored an old 1600-century house. They found that at least one window was shut with bricks and concrete (or the equivalent used at that time), but when they opened it up the whole room changed and the light and the view the window provided was beautiful.

The reason for shutting the window, as Kevin McCloud told, was that long ago there was a window-tax (!!) in England, hence a lot of windows where shut this way.

You get what you measure.

Two steps to become agile

A lot of companies today wants to become “agile”. The $100.000.000 question is: How do you become agile?