July 17, 2015
The term “technical debt” refers to any quality issues within the implementation of an IT solution that hampers your ability to work with or evolve that solution. Technical debt is often thought of as a source code problem, but you can also have technical debt in your user interface design, in your data sources (a huge problem that gets very little attention in the literature), in your network architecture, and in many other places. The existence of technical debt incurs “interest payments” in the form of higher costs to evolve your solution, longer times to do so, and greater overall risk in doing so.
In the Disciplined Agile framework we built in many strategies for dealing with technical debt, including:
In the 2015 Q1 Agile State of the Art Survey we explored how well agile teams were at addressing technical debt. Two of the issues we looked into were what techniques teams are using to avoid technical debt in the first place and what are they doing when they run into existing technical debt.
Avoiding Technical Debt
In the chart below you see that only half of teams are explicitly considering technical debt issues in their design, which is unfortunate because the easiest technical debt is that which you don’t incur in the first place. Worse yet, only one in six people report working on teams where someone(s) received training in technical debt issues. When in comes to thinking through your architecture before you begin construction, roughly half of all agile teams are doing some sort of high-level architectural modeling and one in eight are doing detailed modeling. Half of agile teams either have an architecture owner on the team, are working closely with enterprise architects in an agile manner, or are doing both.
Removing Technical Debt
We’re doing a lot better when it comes to removing technical debt after the fact. Ninety percent of agile teams have adapted the practice of code refactoring, which isn’t a surprise given that code refactoring functionality is now built into most modern development environments. User interface refactoring comes in at a distant second place with roughly one half of teams doing so. Adoption of database refactoring still has a long way to go, in part because of lack of tooling, in part because of a lack of database development skills among developers, and in part due to a lack of agile knowledge and skills amongst data professionals.
Every organization has technical debt that hampers our ability as IT professionals to provide new value to our stakeholders, and sometimes it even affects how we operate existing solutions in production. Technical debt doesn’t pay itself off, the only way to address technical debt is to adopt many if not all of the techniques listed earlier. If your organization has a vision of still being in business ten, twenty, or even fifty years in the future then you need to get started now.
© 2015 Scott Ambler + Associates