Remember back to a time when you worked on a project in college or grade school. You’re pushing through the project, and there is one piece that’s completed, but you know if could be done better. You move on with the rest of the project and tell yourself you will come back to that one piece later on to improve it from good, to great. You continue working on the project and realize you might not have enough time to go back to that one piece to improve it. Instead, you submit the project as is, knowing it could have been better.
It’s a scenario we’ve all encountered, but it’s a part of the IT industry that some may be unfamiliar with. There is a term used in the industry to describe work that gets put off in order to get a project done faster, and it’s known as technical debt. In agile development projects, the “piece” mentioned in the metaphor above could refer to additional testing or building a more robust system. It’s known that corners are being cut, but it’s done to prioritize delivering the system quickly.
The concept of paying technical debt down is no different than paying down financial debt. The issue arises when a company has too much of it, and it never actually gets “paid back” or completed. The difference between technical and financial debt comes in the precision of calculating the debt. Financial debt is straightforward. However, technical debt isn’t easily quantified because often opinions of the way the debt should be resolved varies from person to person.
Technical debt can be problematic; however, sometimes it’s ok to take on technical debt so long as a company is taking on little to moderate amounts of debt. This is because, in some instances, increased debt allows a company to go to market quicker, get feedback from their users and ultimately make more improvements to the technology down the line. However, it is important to note that issues of human safety and security should refrain from taking on any technical debt.
Before starting a project, please consider these three best practices for managing technical debt:
1. Create a list of technical debt
It’s important for companies who are accruing technical debt to keep a detailed list of the debt they are taking on, and make sure it’s included in the list of all other to-do items. When a company has two separate lists of must-dos and technical debt, oftentimes the technical debt is overlooked or not included all together.
2. Create work items to resolve the debt
Accruing technical debt can quickly become overwhelming when you see a long laundry list of items that need to be fixed once you reach the end of a project. One way to avoid this is breaking down the larger items into smaller pieces that are manageable. Additionally, a good rule to follow is allowing for 15 percent of your overall functionality to be spent fixing technical debt, and use the remaining 85 percent working towards new functionality.
3. Build buffer time into your release plan
When working on a project, it’s inevitable that technical debt will be taken on, and while it’s sometimes a good thing, it’s important to make sure the debt is resolved ahead of launch. To do so, build a two week buffer into the release plan that allows for time to sew up any loose ends that occurred along the way. During this time, there will be no new business value brought to the project; it’s solely used to finish last minute items and ensure the release goes smoothly.
The idea of willingly taking on technical debt may be foreign to some business executives. It’s important to be upfront, and bring this up at the start of a project. Taking the time to sit down and talk about it rationally from the start will be easier than addressing a mountain a technical debt at the end of a project.