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.

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.

[spoiler alert: this will reveal the goal of one of the exercises in the course]

Early in the course, the class was assigned a task: Sort a zillion playing cards of different shapes, sizes and types. We should complete the task together as a group, and so we did (to the surprise of Esther and Diana, if I recall correctly).

Afterwards, we were asked what we did to make the group reach its goal. We jotted down our actions on post-its.  It was obvious things like “Sorting cards” and “Clarifying requirements”, but also things like “Step back and get an overview”. We were then asked to place these post-its under some categories:

1. Instructor – coaches others
2. Follower – provides encouragement, conforms to agreements
3. Pioneer – looks for new ideas and ways
4. Influencer – initiates team culture
5. Commentator – puts in context
6. Coordinator – aligns team activities
7. Peacemaker – works for harmony and common ground
8. Promoter – supports quieter team members
9. Critic – looks for risks and weaknesses
10. Gatekeeper – maintains working agreements
11. Reviewer – assure meeting of acceptance criteria
12. Monitor – maintains team relationships
13. Devils advocate – deliberately seeks other views

These are the Team Leadership Roles. They can be further categorized into the activities Direction (1-4),  Guidance (5-8) and Evaluation (9-13).

Up until that moment I had defined leadership in terms of taking the lead. Esther and Diana re-defined leadership as making a group reach its goals. This means that you can take leadership responsibility for your team and your goals even when you support another persons ideas, or when you play the Devils advocate, or when you negotiate a compromise (Peacemaker).

Over time in a successful team these roles must be filled, and anyone can fill a role, they are not bound to a specific individual. It is not even desirable that a single person fills the same role time and time again, since after a while, people will stop listening. An example of this is if the same person plays the Devils advocate too many times, he or she will just be considered negative in general.

It is also important to actively let people shift roles, e.g. the promoter can help a follower to take on an influencer role if that is what he/she would like to try.

I would say that this is an essential part of modern leadership. It has made me more comfortable in day-to-day team work because I can just support another idea and still know I practice leadership. In the same way, we all can practice good leadership in our own way, because we are all leaders. You are a leader.

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.

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.

<script type="text/javascript">
// Open a dummy window without navigation bar to
// get a reference.
dummy = window.open('url', 'windowname',
'height=200,width=200,status=0,toolbar=0,' +
'menubar=0,resizable=0,scrollbars=0');
// Calculate bottom bar height
bottomBarHeight = dummy.outerHeight-dummy.innerHeight;
dummy.close();
// Calculate the navigation bar height
topNavigationHeight =
  window.outerHeight-window.innerHeight-bottomBarHeight;

// Create a function to use repeatedly
function findScreenPos(obj) {
	// Calculate the total screen offset
	screenTopOffset = window.screenY
                          + topNavigationHeight;
	screenLeftOffset = window.screenX;
	pagePosition = findPos(obj);
	return [screenLeftOffset+pagePosition[0],
                screenTopOffset+pagePosition[1]];
}
// Gotten from http://www.quirksmode.org/js/findpos.html
function findPos(obj) {
    var curleft = curtop = 0;
    if (obj && obj.offsetParent) {
	    do {
	         curleft += obj.offsetLeft;
	         curtop += obj.offsetTop;
	     } while (obj = obj.offsetParent);
    }
    return [curleft,curtop];
}
</script>

Thanks to QuirksMode for the function that provides the position within the document.

If you know how to do this in a better (or more beautiful) way, please write a comment. I spent several hours on Google just to get here.

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…

The Hydra

Our approach was that we should do what we needed to do, fix all the compiler errors, run all the tests, check-in, done. Yeah, right…

We did what we wanted to do, got about 20 compiler errors and started fixing them. When we were just about done, the compiler could move a step forward and showed us yet another bunch of errors. When trying to fix them we had to make new re-factorings, that in turn created new errors.  So we went on, and every day on the daily stand-up we said that “We just have a couple more errors to fix, but we will probably be done today or tomorrow”. Yeah, right…

After more than two weeks of working like this, with 1200+ files checked out, 200+ compiler errors we had to face it. We would never make it. We were trying to behead the Software Hydra, but for every head we cut off two more grew out. We had to make the tough decision to revert everything we had done. But, as Tom Poppendieck always say: There is no failure but the failure to learn. And did we ever.

Go with the flow

We had realized that we had been walking with the refactoring dependencies, i.e. we tried to re-factor a part of the code that was depending on that another refactoring already had been done, which it hadn’t. If we could just walk with those dependencies, or prerequisites, until we reached a re-factoring that had no prerequisites, a leaf in the dependency graph, then we could just do that refactoring without any hassle. And by doing that, we would have fulfilled the prerequisites of another re-factoring that now had become a leaf, ready for execution. By doing so with all prerequisites, eventually our goal would be met!

The Mikado Graph and the Mikado Method

The Mikado Graph

When we presented this method at SDC2009, Laurent Bossavit suggested that this dependency graph and dependent refactorings had great similarities with how the Mikado Game is played. In order to get to “The Emperor”, you cannot just pick-up that stick. First you have to pick up all the sticks that in some way is above that stick. We thought it was an excellent observation and we now call it The Mikado Method and the dependency graph is called The Mikado Graph, as suggested by Laurent.

The Naive Approach

In our real-world case, we drew the Mikado Graph on a whiteboard, step by step. To do that, you naively start with the thing you want to achieve and draw that on your Mikado Graph, typically a business goal. Try to implement that change. If that goes all well, you are done. Check-in. Congratulations!

In most cases, however, you end up with compiler errors or tests that don’t run. Examine the errors and failed test and come up with measures that would have prevented those errors or test failures. This is often other refactorings in the application. Those measures become sub-goals to you business goal. Draw them on the graph as well, with arrows pointing from the business goal to the sub-goals. Revert the code to the previous working version.

Now, for each of the sub-goals repeat the process by naively trying to achieve them. Draw the solutions to the new issues as new sub-goals, revert the code, attack new sub-goals and so on. In the end, you can actually implement a leaf sub-goal while the application still works. Great! You just got one step closer to achieve your business goal.

By doing the refactorings from the leaves and in the opposite direction of the dependency arrows, you will eventually achieve your set out business goal.

The Mikado Graph Done

Good luck!

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.

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

I seem to do that from time to time. As soon as you need to handle a case a little out-of-the-ordinary, the tool breaks. Where should you put this thing? How should you present it? What looked like a walk in the park suddenly becomes a mess.

If you have a whiteboard you just draw a square somewhere and put a post-it or a note there, and just by doing so you have communicated “This is a one-off, but its important since it is on the board”. The team-members will see it and understand. Elapsed time: 1 minute.

In the case that the tool is flexible you can probably configure it. But then it is usually configurable beyond all reasonable limits. Tools must have “ticks in all the boxes” to compete with all the other unreasonably configurable tools. This configuration, including learning how to configure it, takes a lot of time since the tools are very configurable. And it might not be possible to do what you want anyway. Elapsed time: days? weeks?

The tools try to cover all possible future cases of configuration, based on previous projects and not the current. Hmmm, this sounds familiar. Waterfall, anyone?

The funny thing is that you get the same characteristics from such a tool as from the waterfall process, or from trying to control any empirical process using only feed-forward control, i.e. “planning ahead”. Small irregularities can make a big impact.

The meta-process of configuring your process is also empirical. If you use a whiteboard you adapt the board and your process only to the current project. This makes using a physical visible planning tool more robust in the face of irregularities.

For the record, the tools usually provide a lot of interesting functionality that can be useful, but you’d better have an off-line option to handle the quirks. But then you have two systems, and that might not be optimal either.

Also, for globally distributed teams the argument is that “you need a tool”. I rest my case there, just asking if you really need a globally distributed team? But that is probably another blog entry…

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.

If you find an old Swedish mirror of some size, you will see that the mirror glass is often split in two or more pieces. When I first saw this I assumed it was because they didn’t know how to make larger pieces of mirror glass.

But, the real reason for this was, as in the case with the English windows, there once was a mirror tax in Sweden for mirrors larger than a certain size, hence mirror glass were cut in smaller pieces to avoid the tax.

You get what you measure.

In the average company, the same behavior is often seen where managers try to control their organizations by detailed measuring. In software development it is common to measure things like lines of code produced, number of people in a project, or produced documentation. This usually renders in… many lines of code, lots of people in the projects and piles of documentation. Wasteful and without customer value.

You get what you measure.

So, what should you measure?

In lean organizations, and promoted by lean software development, measure up is an important principle to avoid local optimizations. Local optimizations are bad because they consume resources that could be better used at other places, and they could create bottlenecks and lock-ups and it is likely to result in dysfunctional organizations.

Running Tested Feature (RTF) is one way of measuring up in a software developing organization. It lies above all detailed code metrics and it measures the whole development effort. The RTF index should be constantly increasing, otherwise there is a problem.

Net Promoter Score (NPS) is another way to measure up. Ask the user of a product “On a scale from 0-10, how much would you recommend this product to your friends and family?”. Promoters and detractors are detected this way. Promoters are also likely to be a good source of information for how to improve the product since they are more likely to have used the product extensively.

If you think RTF or net promoters is a good thing, start measuring those things instead of detailed, micro-managing metrics that will result in bad behavior and local optimizations.

You get what you measure. In a good way this time.

There are of course other ways of measuring up in a healthy way. If you have come across someting that you find interesting and useful, please make a comment.

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

These are the two steps you need to do:

1. Arrange totally honest retrospectives every week
2. Execute, with no exception nor delay, all the solutions, impediment removals and improvements as suggested by the retrospectives

If you do this, you will be doing agile.

Simple? I doubt it…