Technical debt is a frequent topic in blogs covering agile software development. But it’s not the only type of debt incurred by software development teams. There’s no shortage of ways for software developers to dig deep holes for themselves.
This post explores other forms of debt that lie in wait for the unsuspecting development team. You may knowingly choose to incur short-term debt with the intent to pay it off before it gets too large. Alternatively, you may choose to avoid any indebtedness so you’ll never have to deal with repayment issues. It’s up to you.
If you decide to take on some debt to meet a critical deadline or satisfy a business need, document it and keep track of it. If the product or service you’re supporting is short lived, the debt won’t matter. If you find yourself adding many new features and upgrades, the debt will likely have to be paid off eventually.
Some of the following debt types are subsets of technical debt (i.e. defect, performance and size) while others represent different types of debt (i.e. backlog, competitive, learning, testing and useability). Some are more sinister than others but they are all formidable challenges.
Software Development Debt Types
Backlog debt – The story backlog just keeps growing. The team does a reasonably good job of delivering completed stories but they arrive at an even faster rate.
Recommendation: Either expand the software development team (this may require adding another team) or push back on the product owner and the stakeholders encouraging them to focus on what really matters in the software.
Competitive debt – Your company’s competition gets new products and services to market faster than you and grows its market share.
Recommendation: Your team is too slow. You need to crank it up. Consider adding more (and better) people. Avoid seeking perfection in the product or service. Make sure the software is “good enough” and move on.
Defect debt – The bug count keeps increasing despite the team’s best efforts to fix bugs.
Recommendation: Your team is sloppy. Make good engineering practices a priority. Focus on preventing defects using pair programming, code reviews, test-driven development and related techniques.
Learning debt – New technologies and tools are appearing yet the team continues to use what it knows and lacks the skills it needs to adopt new ones.
Recommendation: Allocate time for training, learning and experimenting. Just do it. Identify technologies and tools that will benefit the company. Make a strong argument for acquiring the skills and push for them.
Performance debt – The software system’s response time keeps increasing. It takes longer and longer to perform routine tasks.
Recommendation: This is similar to defect debt in that good engineering practices will help. Set performance goals, include them in acceptance criteria, and incorporate performance testing into the development process.
Size debt – Memory usage keeps increasing. The software’s footprint keeps growing and as it does, load times get longer.
Recommendation: Memory handling problems can be vexing. They creep up on you and get out of control. Be vigilant. Monitor memory usage during test runs. Identify memory hogging areas of the code and improve them.
Testing debt – The percentage of the system not regression tested keeps increasing. QA has their hands full keeping up with new features.
Recommendation: It’s only natural to focus on testing new features and functions. However, regression testing is almost as important. Hire good testing talent and invest in automated testing tools.
Usability debt – The software becomes more complex and difficult to use. Feature creep produces so many options that many users are overwhelmed.
Recommendation: Usability is often driven by the software developers. Yet, what makes perfect sense to them may be unintelligible to the average consumer or business person. At a minimum, conduct periodic usability reviews and make implementing the feedback a priority.