Paying Off Technical Debt

We don’t get spam about how to consolidate our technical debts. :-) Image credit: Alan Cleaver (Flickr)

“Interest never sleeps nor sickens nor dies; it never goes to the hospital; it works on Sundays and holidays; it never takes a vacation; it never visits nor travels; it takes no pleasure; it is never laid off work nor discharged from employment; it never works on reduced hours. . . . Once in debt, interest is your companion every minute of the day and night; you cannot shun it or slip away from it; you cannot dismiss it; it yields neither to entreaties, demands, or orders; and whenever you get in its way or cross its course or fail to meet its demands, it crushes you.”

J. Reuben Clark

In my recent post about how organizations forget technical debt, I glossed over some important details. When you’re in debt, you have an obligation to pay somebody back. So: with technical debt, who must you pay, and how?

More than just a code problem

A simplistic view–one that I’ve used for years–understands debt mainly as a deficiency in code. In this view, you pay yourself back by making the code better. Most discussions about technical debt take this view. It’s natural, and true, and useful.

However, I don’t think it’s the full story.

It’s good practice to borrow money from yourself. If you do things this way, you save a bunch of capital, and then you borrow against your own reserves. Paying yourself back consists of transferring money back into your own savings.

This is hard, and making large purchases this way requires years of prior planning and discipline.

A more common way to borrow is Continue reading

Coping With Organizational Alzheimers

Years ago, an astute manager summed up a problem that I had only vaguely intuited up to that point in my career.

Do our memories leak? Image credit: xpectro (Flickr)

“A big problem with most companies,” said Roland, “is that they have no institutional memory.”

As I recall, Roland was describing capricious political winds, and lamenting that the only form of loyalty a company has to employees is the kind they put in writing. As soon as there’s major M&A activity, or HR decides to rebalance salary allocations, or an incentive program gets adjusted to the latest management fad, all recollection of old priorities and soft obligations vanishes in a puff of smoke.

If anything, Roland was understating the problem. Companies routinely panic and change strategy half-way through an investment cycle, because they can no longer articulate the rational analysis that led them to take a plunge. Buzz floods the internet about some innovation that makes everybody excited, but we forget that we’ve heard the idea before, behind some different terminology. (Are you nodding your head because “cloud” in the last few years is just a recycling of “utility computing”from circa 2000? Trev, a colleague of mine at Adaptive Computing, showed me a dog-eared copy of The Challenge of the Computer Utility, by Douglas Parkhill. It’s all there–XaaS, elastic and on-demand, in 1966. And who knows–maybe sci-fi writers or the designers of Eniac had thought of it even before Parkhill…)

But I digress.

One particularly insidious form of forgetfulness in software relates to technical debt. Another colleague, Doug, reacted to an expedient workaround this way:

My one regret with this is that by doing something that is good enough it will never get the attention it might deserve to be made better. This happens each release: we make compromises at the very end to get it out the door, promising ourselves that we’ll revisit it later.

Folks, we don’t keep these promises to ourselves very well; Alzheimers is endemic with regards to technical debt. The only thing that saves us is that Continue reading