While perusing the news this week, I happened on a mention of the term technical debt, an intriguing concept for IT professionals involved in software development -- and one that could become more important across IT as collaborative and cloud computing broaden in scope and budgets continue to tighten.
The term apparently was coined by Ward Cunningham, a legend in the area of modern programming methods, such as agile programming and extreme programming, and the man credited with developing the first wiki.
In a video, Cunningham explains that he originated the metaphor of technical debt as a way to describe the concept of developing software without all the bells and whistles a programmer might like to add in the future. Example: rushing out a product to get it in customers' hands, knowing you'll have to revise -- or "refactor" -- it later on.
While working on a Digital Smalltalk project, for example, Cunningham told his boss that if a program had to be refactored, or rewritten to some extent after it had been released, it was like borrowing money and paying interest on a loan:
I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
The "trick" is to avoid having to avoid technical debt by writing code in a way that makes future changes and enhancements easy -- and cheap. Here's how software expert Martin Fowler described the challenge a few years back:
Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
The technical debt concept isn't easy to nail down in dollars and cents. It calls for some pretty detailed calculations, based in part on how much individual developers are paid and how long it will take them to fix a problem or add a feature.
But mastering the concept of technical debt can produce some powerful business results. For example, blogger and agile programming expert Israel Gat has suggested, among other uses, that "the monetized technical debt on the balance sheet of a software vendor is a proxy for the technical risk involved in licensing software from this vendor."
Gat also has written that technical debt can be used by venture capitalists to determine whether or not a software product is really worth funding.
The concept of technical debt might have other applications, too. In a recent blog, tech investor Ben Horowitz discusses how the idea can be applied to managing staff. (In his interesting adaptation, Horowitz figures it's better for CEOs to make unpopular personnel decisions up front, rather than pleasing everyone and paying out longer-term "interest" in excessive compensation, counteroffers for disgruntled employees, and poor company performance due to poor management.)
The concept of technical debt also has spawned some solutions and much discussion thereof. There also have been exhortations to build technical equity. The literature on this topic is varied and nearly always intriguing.
Whether you "buy into" the concept or choose to augment it somehow, the idea that all enterprise applications live on borrowed time can certainly help many groups make better use of their resources.
— Mary Jander 
, Managing Editor, Internet Evolution
Email This
