Technical Debt Analogy

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

I was reading a book called ‘Software in 30 Days – How Agile Managers Beat the Odd, Delight Their Customers, and Leave Competitors in the Dust‘ by Ken Schwaber and Jeff Sutherland , and there was a fantastic analogy that summed up technical debt, which I wanted to quote for you here.

As technical debt grows it becomes harder and more expensive to fix over time.

As technical debt grows it becomes harder and more expensive to fix over time.

In cold climates, when the temperature drops, the pipes in houses often start knocking. Whenever you turn the water on at the tap or use the washer or dishwasher, whenever the heating system starts up, the pipes start banging against one another, against the framing, and against the walls. Sometimes they sound like a jack-hammer, especially when they start knocking in the middle of the night. Knocking pipes are hard to fix. They rattle because they weren’t properly secured. When they become loose and knock, precisely locating them is difficult.

The knocking may be happening at a different place from the insecure pipe. Over time, they become looser. It is difficult to find the exact place where they should have been secured, as the noise may be located a short distance away. Frequently, you have to make a large hole in the wall, remove any insulation, and start looking. Then, with a little luck, you can secure the pipe properly. The cost of securing a pipe correctly when it is installed differs minimally from securing it incorrectly. The cost of securing it once the building already has been constructed is much higher.

There is a powerful lesson here in that you should try to build your software as best as possible from the start. If you start making compromises in the design and testing, then you will create technical debt which you will have to pay back later, but you always end up paying it back with a lot of interest.

It is far more efficient to get a design and code right from the start. It may take to a little extra time up front to get it right, but this will always be less time than trying to fix it later. What inevitably happens, is that the issue doesn’t get fixed as you will be under constant pressure to add new features.

You would hope that companies would learn by their mistakes and allows the developers to fix any issues at the front, but sadly in my experience this isn’t always the case. Of course, not all technical debt is evil. You need to work through the potential issues with your team as they are preparing for releases. Some technical debt maybe a justifiable, but you need to consider it carefully. In my mind technical debt is more often bad then acceptable.

Here are some good resources on Technical Debt Management.

Scrum Alliance : Managing Technical Debt

Martin Fowler : Technical Debt

InfoQ : Technical Debt

One thought on “Technical Debt Analogy

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s