This blog is the first in a series of blog postings regarding the concept of technical debt. The content of this blog is based on my book Essential Scrum: A Practical Guide to the Most Popular Agile Process.
Technical debt is a term used to describe the obligation that a software organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term. To facilitate a discussion on technical debt I use the following taxonomy to describe how technical debt might be accrued:
- Naive technical debt
- Unavoidable technical debt
- Strategic technical debt
Let me describe each of these.
Naive technical debt
Naive technical debt is a form of technical debt that accrues due to the irresponsible behavior or immature practices on the part of the people involved. For example, team member naiveté that leads to sloppy design, poor engineering practices, and a lack of testing are frequent causes of naive technical debt. Business people immaturity can also lead to this form of debt. For example, by over-constraining the variables of date, scope, and budget, business people frequently force technical people to take shortcuts to deliver an unreasonably large set of features in the face of insufficient time or resources. It is naive for business people to believe that just because they want (or must have) all the features by a given date at a certain price that they can get it at a reasonable quality level!
Unavoidable Technical Debt
Unavoidable technical debt is a form of technical debt that is usually unpredictable and unpreventable and accrues through no fault of the team building the product. A common example is the need to evolve a design over time as we learn more and more about the problem we are solving and how best to solve it. It is unrealistic to assume that early on during the development of a product, when we have rather poor information about what to build and how to build it, that we can come up with a design that will work well both now and in the future. As we gain better and better information about what we are building and how to build it, an early design that seemed quite satisfactory or even brilliant when created can become far from adequate in ways that we could have never predicted when the original design was created. In this sense we have accrued unavoidable technical debt. We will want to refactor the design to make it better suited to our new current reality.
Another example of unavoidable technical debt would occur if we licensed a third-party component for use in our product and the interfaces to that component evolve over time. Our product that once functioned well with the third-party component accrues technical debt through no fault of our own. Although this debt might be predictable (it’s not unreasonable to assume that the vendor will change its component interfaces over time), it’s not preventable because we can’t foresee how the component developers might evolve the component in the future.
Strategic Technical Debt
Strategic technical debt is a form of technical debt that is used as a tool to help organizations better quantify and leverage the economics of important, often time-sensitive, decisions. For example, an organization might deliberately make a strategic decision to take shortcuts during product development to achieve an important short-term goal, such as getting a time-sensitive product into the marketplace. Also, for a capital-strapped organization that is at risk of running out of money before it can complete its product, getting a product with technical debt to market at a reduced initial development cost and then generating revenue to self-fund ongoing development may be the only way for the organization to avoid death before deployment.
To use technical debt strategically, we must properly understand how it affects the economics of our decisions. First we must reasonably quantify what is the benefit of accelerating a product into the marketplace. Then, we must compare that benefit against the incremental cost of having to repay the technical debt with interest in the future. We also have to factor in the time it will take to repay the debt, and then determine what the cost of that time is in terms of delaying other products or the next release of the current product.
Closing
The purpose of this blog was to introduce a taxonomy for discussing how technical debt is accrued. In the next blog posting on this topic, I will begin to address how to manage technical debt when performing agile development.