I attended an Agile roundtable this evening, and one of the sponsors, Jonathan Rayback (an Agile thought leader in the Salt Lake City area) introduced me to the concept of "technical debt". It's been around for a long time (at least since 1992), so I'm late to the party, but the idea really resonates with me.
The term was apparently introduced by Ward Cunningham, and has been expanded upon and clarified by Steve McConnell, among others.
Here's the definition supplied by the venerable (but oft maligned) Wikipedia (hyperlinks removed):
Jonathan illustrated the idea with a whiteboard graph that looked something like this:
In this chart, the project was expected to be completed in about 20 days. About 13 days into the project, it became clear that an additional 4-5 days would be required to complete it in a high-quality way. However, a business decision was made to stick to the original schedule by working more hours, cutting corners, or making some other compromise.
The area between the red line (the business-mandated schedule) and the green line (the "ideal" schedule, for the sake of quality) represents the business debt incurred during the course of the product.
Like financial debt, technical debt must be repaid at some point. And, like financial debt, not only the original principal will need to be repaid (in the form of refactoring, bug fixes, etc.), but also accrued interest (customer complaints, support calls, etc.)
To advance the metaphor further, Jonathan pointed out that not all technical debt is bad.
Most of us who own homes owe a sizable financial debt in the form of a mortgage. Did I make a mistake by going into debt to own my home? Certainly not: I estimate that my family's housing expenses over the past 11 years have been far less than they would have been if we had been renting during that time, even if we had lived in a much smaller home. It would have been ridiculous to wait to buy a home until we had saved up enough money to pay for one.
In the early stages of developing our software and service offerings at AdvancedMD, we incurred huge technical debt. We've had good-natured debates about whether that was a mistake or not. On the one hand, our coding and deployment efficiency is lessened by shortcuts we've taken in the past. On the other hand, we were first to market with a web-native PMS (by years), and we remain light years ahead of our nearest competition.
We've also made great strides towards paying off that debt (and minimized the accumulation of new debt as much as possible). We've rearchitected major components of our application over the years, so that, as a whole, I'd put our code up against just about anyone's. Sure, it would have been great if we hadn't had to do that rework, but, again, in most cases the debt was justified.
Not all technical debt is created equal. Here's how Steve McConnell categorizes technical debt:
Non Debt
Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.
Debt
I. Debt incurred unintentionally due to low quality work
II. Debt incurred intentionally
II.A. Short-term debt, usually incurred reactively, for tactical reasons
II.A.1. Individually identifiable shortcuts (like a car loan)
II.A.2. Numerous tiny shortcuts (like credit card debt)
II.B. Long-term debt, usually incurred proactively, for strategic reasons
Only debt in Category I should be a source of embarassment...and, yes, we have our share of that kind of debt, although far less than a few years ago.
I make no apologies for the other types of technical debt that we've accrued, because we've overcome the odds by proving both our technology model (which, in 1999, was utterly original) and our business model.
The term was apparently introduced by Ward Cunningham, and has been expanded upon and clarified by Steve McConnell, among others.
Here's the definition supplied by the venerable (but oft maligned) Wikipedia (hyperlinks removed):
Technical debt is a term coined by Ward Cunningham to describe a situation where the architecture of a large software system is designed and developed too hastily.No one who has been developing software professionally for more than 5 minutes has been able to avoid technical debt.
Jonathan illustrated the idea with a whiteboard graph that looked something like this:
In this chart, the project was expected to be completed in about 20 days. About 13 days into the project, it became clear that an additional 4-5 days would be required to complete it in a high-quality way. However, a business decision was made to stick to the original schedule by working more hours, cutting corners, or making some other compromise.The area between the red line (the business-mandated schedule) and the green line (the "ideal" schedule, for the sake of quality) represents the business debt incurred during the course of the product.
Like financial debt, technical debt must be repaid at some point. And, like financial debt, not only the original principal will need to be repaid (in the form of refactoring, bug fixes, etc.), but also accrued interest (customer complaints, support calls, etc.)
To advance the metaphor further, Jonathan pointed out that not all technical debt is bad.
Most of us who own homes owe a sizable financial debt in the form of a mortgage. Did I make a mistake by going into debt to own my home? Certainly not: I estimate that my family's housing expenses over the past 11 years have been far less than they would have been if we had been renting during that time, even if we had lived in a much smaller home. It would have been ridiculous to wait to buy a home until we had saved up enough money to pay for one.
In the early stages of developing our software and service offerings at AdvancedMD, we incurred huge technical debt. We've had good-natured debates about whether that was a mistake or not. On the one hand, our coding and deployment efficiency is lessened by shortcuts we've taken in the past. On the other hand, we were first to market with a web-native PMS (by years), and we remain light years ahead of our nearest competition.
We've also made great strides towards paying off that debt (and minimized the accumulation of new debt as much as possible). We've rearchitected major components of our application over the years, so that, as a whole, I'd put our code up against just about anyone's. Sure, it would have been great if we hadn't had to do that rework, but, again, in most cases the debt was justified.
Not all technical debt is created equal. Here's how Steve McConnell categorizes technical debt:
Non Debt
Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.
Debt
I. Debt incurred unintentionally due to low quality work
II. Debt incurred intentionally
II.A. Short-term debt, usually incurred reactively, for tactical reasons
II.A.1. Individually identifiable shortcuts (like a car loan)
II.A.2. Numerous tiny shortcuts (like credit card debt)
II.B. Long-term debt, usually incurred proactively, for strategic reasons
Only debt in Category I should be a source of embarassment...and, yes, we have our share of that kind of debt, although far less than a few years ago.
I make no apologies for the other types of technical debt that we've accrued, because we've overcome the odds by proving both our technology model (which, in 1999, was utterly original) and our business model.
No comments:
Post a Comment