Over the past 10 years or so, it has been interesting to watch the metaphor of Technical Debt grow and evolve. Like most topics or issues in software development, there aren’t many concepts or practices that are fully embraced by the industry without some debate or controversy. Regardless of your personal thoughts on the topic, you must admit that the concept of Technical Debt seems to resonate strongly outside of development teams and has fueled the imagination of others to expound on the concept and include additional areas such as design debt or other metaphors. There are now a spate of resources dedicated to the topic including the industry aggregation site: OnTechnicalDebt.com
We recently had David Norton, Research Director with Gartner Research as the guest speaker on a webinar, “Get Smart about Technical Debt”. During the webinar, Mr. Norton was passionate about the topic and he believes that Technical Debt will transcend the casual use by architects (and marketers) to find a more permanent place among the vernacular of CIOs and CFOs. Spend just a little time with Mr. Norton and it is clear that he is on a quest to drive the concept as an important indicator of risk, and the practice of measuring and monitoring Technical Debt will soon become a requirement as the industry continues to mature.
In my personal view, Technical Debt, although not perfect, is one of the few development metrics that rises above the techno-speak of the dev team. Technical Debt seems to resonate because it attempts to quantify the uncertainty within a product or development process—an uncertainty that underlines all the years of process improvement initiatives, training classes, project management tools and overhead that is typically forced upon dev teams.
I believe that rather than fighting this metaphor, dev teams should embrace Technical Debt and work with the organization to create a common definition and method for calculating it. It takes very little overhead to provide on-going measurement once a definition and method is determined. To me, the value to the development organization is that we are now armed with a “hard cost” for poor or myopic decisions.
I really enjoyed Mr. Norton’s passion and the great discussions/questions from those that joined us on the webinar. If you missed it you can watch the recording here. I’d be interested in your take on his view.
If you want to learn more about Technical Debt, there are some great resources listed below:
- Java Application Architecture: Modularity Patterns with Examples Using OSGi (Agile Software Development Series) by Kirk Knoernschild
- The Economics of Software Quality by Capers Jones and Olivier Bonsignour
- Paying Down the Interest on Your Applications: A Guide to Measuring and Managing Technical Debt white paper from CAST
- The CRASH Report – 2011/12 (CAST Report on Application Software Health)