Strategic advice to leverage new technologies

The DeLorean system is the long-time production system one of my clients relies on to expose its entire business via the Web. The client had successfully developed, evolved, and sustained this system, and its successful business, for more than a handful of years. A few years past that point, it started becoming evident that the system was growing increasingly inflexible and brittle.

Every development manager has faced the choices: Ship sooner? Squeeze in an extra feature? Test a little less to cut cost? Invest in infrastructure? Rewrite that problematic code? Virtually every development cycle goes through a similar set of tradeoffs multiple times in the course of getting code out the door. Every time a decision is made, the overall quality, maintainability, complexity, and stability of a software system goes up or down.

I've been familiar with the term "technical debt" for nearly a decade now, and I remember how it first resonated with me as a way to describe the insidious complexity and entropy that slowly creeps into software systems. I've taught many teams about the notion of a technical credit card that can eventually become maxed out, such that you can no longer add features to a system without significant effort.

When talking about debt in software, there tends to be a focus on the code itself. This type of software debt is described as technical debt. Although this is an important type of debt to manage in software development, there are other aspects that must be tended to as well. Software debt includes the following:

• Technical debt -- issues found in the code that will affect future development, but not those involving feature completeness

Acceptance tests are performed by an end user or system owner to verify that delivered software functions correctly and meets requirements.1 Acceptance test debt is the nonexistence or nonautomation of acceptance tests. Developing product features is more risky when an organization has acceptance test debt. The debt corresponds inversely to the proportion of requirements that are covered by automated acceptance tests. To reduce the risk, you need to decrease the debt.

Much has been written about the mechanical aspects of technical debt. Cutter Senior Consultant Kent Beck and Martin Fowler first cataloged what we call code "smells" in 1999. The book in which this catalog of smells appeared is commonly known as "the Refactoring book,"1 and it is a well-known source on the subject of technical debt. But Fowler's book and other writings like it don't address the causes of technical debt. Rather they point out what it is and how to fix it.

Our understanding of what constitutes technical debt changes as our experience and technology advance. Today's best practice inevitably becomes tomorrow's legacy system. The metaphor of technical debt originated before the client-server model became the dominant computing paradigm and hasn't been as widely applied and analyzed in systems. We now have the lessons of nearly two decades of experience managing Web architectures to reflect on.

Early this year, fellow Cutter Consultants Mitch Ummel, Mike Rosen, and I wrote an Executive Report on the Smart Grid (see "