Strategic advice to leverage new technologies

If the maxim "what gets measured, gets managed" should be used to judge the use of social media in companies, then clearly the topic is moving beyond mere casual interest. Cutter Consortium's recent survey on the topic makes that abundantly clear. However, until I analyzed the results of the survey, I felt that many in industry were thinking somewhat schizophrenically. Most CIOs and business leaders I talk to are -- themselves singly or speaking for their organizations -- of two minds regarding social media.

This issue of CBR was quite interesting and a lot of fun to write about. It centers on a very timely and increasingly pervasive topic: social media, focusing our attention on the monitoring of the social media landscape by organizations. As the saying goes, and which Vince alluded to in his contribution, you can't manage what you don't measure. While the old saying may or may not be true, what is sure is that measuring is costly, in terms of time and the expense associated with the right tools.

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