Pretty image
When technical debt is out of control, who you gonna call?

In 1992 Ward Cunningham drew the comparison between technical complexity and debt, writing: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite...."

I remembered this as I watched a documentary series about a debt counselor on German television. "Hey, if there is something like technical debt in our software projects," I thought, "we should have technical debt counselors too!"

The more I thought about it, the more appropriate this stretching of the metaphor seemed. So let me stretch this metaphor a little more. If there were a technical debt counselor, what would such a person actually do?

Developing a metaphor requires mapping elements of one domain to corresponding elements in another. So first, we will map a feature that we need in our project to some cool thing that we can buy for money. The price we will pay for the cool thing is then a proxy for the time we need to develop and ship the new feature.

Credit Cards Ready?

OK, here we go. We are going into debt.

In the documentary series I mentioned above, people who are now loaded with debt got there by falling for (or to be less judgmental, taking advantage of) offers like: "buy now, pay later" to get all the cool things of their dreams.

So what about our cool, new software project? How do we get into technical debt? Well, first we need developers. (The inexperienced ones are cheaper so we hire more of them for the team.) Then we start the project, with good requirements, a great design, and the resolution to do it right.

Which lasts for a while, but pretty soon we remember that time is money, so we take a few shortcuts and do some hacks to get the features out the door. These are our first technical debts.

There is no problem with debt in general. But debt becomes a problem as soon as we can't keep up the payments. As soon as we can't both maintain our daily life and keep up the repayments. Or on our software project, if we need too long to deliver a feature or if we even can't deliver the feature any longer.

That's bad.

Help! Now What Do We Do?

It gets worse if we don't face the situation, or if we sugarcoat it.

Once you're in over your head, emergency measures are needed. If we went into financial debt, we could go into insolvency to get rid of it. In the documentary, the debt counselor comes to the rescue just before the people go into the insolvency. He tries to avoid the insolvency for them. He sorts out their finances, makes a plan for how to pay the bills and repayments, and as the most important point, regardless of his ability to avoid their insolvency, he trains them in how to organize their lives and how to live without going into debt again.

In our software projects we know such a thing as insolvency too. We call it rewrite.

But why do we not have technical debt counselors? We need such a person, who tells us how to save our project without a rewrite. And most important, as with the financial debt counselor, a technical debt counselor would show us how to write the code and how to care about and avoid technical debt.

He should help us to create a working process, coach the team how to take care for their project and train them on techniques to work with legacy code and how to use tests. He inspires us to do quality work.

In short: He helps us to do a great project!

Where Are the Technical Debt Counselors?

If you've ever heard a coworker say, "A rewrite every three years is normal" or saw a project that couldn't deliver needed features, you know it's true: We need technical debt counselors.

Too bad we don't have any.

That is, I don't know anybody whose business card reads "technical debt counselor." Not yet. But there is a movement called software craftsmanship. That's where I would look for the technical debt counselors of tomorrow.

Christoph Pater works as software engineer and scrum master at adesso mobile solutions. He writes the German blog "Software Leid(enschaft)" and organizes the local software craftsmanship community in Dortmund (Germany).

Send the authors your feedback or discuss the article in the magazine forum.