It’s often impossible to fix all the issues before releasing the software, even if you’re using software testing tools. Time constraint and large amounts of bugs pose a dilemma, either the release can be delayed to give developers the time to fix issues, or the team can respond with quick and suboptimal fixes that will sufficiently address only the high-priority problems. The quick-fix option will defer the issues to be fixed later. This generates technical debt: a temporary compromise that permits the fulfillment of higher-priority business objectives. Anything that is intentionally deferred is the technical debt that requires an interest payment when it becomes necessary to redesign and rewrite a better solution. However, technical debt isn’t merely about deferring a reconstruction. It’s the entirety of what the team owes to the product, such as current database schemas and missing tests.
Technical debt doesn’t only add burden on the testers, it also affects the clients and the users. Clients want fast delivery at the cost of minimum resources. That’s why they often don’t care about the code quality as long as it’s getting things done. However, technical debt will require far more time, effort, and resources to maintain and develop later, the extra cost of which is likely to significantly surpass the initial gains. Users, on the other hand, want a reliable application that is regularly updated with new features. With a lot of technical debt to deal with, promising user requirements can be a problem.
As a test manager, your priority should be to avoid technical debt as much as possible. It’s impossible to prevent all of it but it gets hard to manage if it keeps on piling up. Following are a few things you can do:
- Keep the best software testing tool in your arsenal
- Document all issues
- Regularly review codes without digging deep
- Do not neglect automated testing
- Use an agile approach
- Focus on understanding the problem rather than finding the person to blame for it
It’s important to note that even if you avoid stacking up technical debt as much as possible, you still have to deal with some. It can’t be avoided, so it’s imperative to implement practices and processes to keep them at bay.
High-Interest Technical Debt First
Interest in the case of technical debt is the additional effort and resources that need to be put to deal with the debt. For some critical debts, the interest significantly increases over time. Therefore, it’s important to deal with them first. Identify what to address and what not to. Cruft at a part of code that is used and changed often is far more important than cruft at a part that is barely ever used or changed. This is high-interest debt because there is a lot of work done around it. Unless it’s not dealt with, this debt can hamper all the work, forcing more technical debt to be added to other parts of the code. So whenever possible, prioritize these issues first.
Boy Scout Rule
Boys scouts are trained to leave the campsite in better shape than they found it. Similar instructions are given to the developers: fix the technical debt when you find it. Without defined boundaries, technical debt can be very time-consuming. Determine a percentage time in each sprint to fix any debt developers may find. Depending on the situation, anywhere from 5-33% could be a good option.
Repay Debt While Performing Valuable Customer Work
Dedicating entire sprints towards fixing technical debt gives the client the impression that you are spending their time and money to fix something you did wrong in the first place. It also suggests that you’ve probably paid higher interest on the debt already than was necessary. It’s better to designate a maximum amount of time spent repaying technical debt in each sprint and use it to fix high-priority or happened-upon issues. It keeps the client happy, and it keeps technical debt at a manageable level.
Just Ignore It
When a product is near the end of its life, if it’s built for a short cycle or if it’s a throwaway prototype, technical debt is not a major concern. These instances are few and far between, but you can save some time and effort when they do come up.
Conclusion
For developers and testers, technical debt is as significant as debt in real life. It’s better to avoid them, and if you can’t, repayment is a must. For both, there is no clear-cut solution. However, through thorough work, strong coding principles, and a well-set-up work process, technical debt can be managed and kept at bay.
