Randy Rayess
In the early 1920s, Ward Cunningham, in a report for OOPSLA ’92, talked about accruing debt when working on a software project. Drawing upon the analogy of financial debt, he said,
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”
His observation sparked a debate within the software community, inadvertently leading to the coining of the metaphor ‘Technical Debt’, a metaphor that has come to guide software development for more than two decades now.
Like he mentioned in the report, a little technical debt, incurred strategically as part of the development plan is good. We all understand the need to adhere to deadlines and ship the product urgently. However, a concerted effort has to be made to not let the debt get out of hand and lead to technical bankruptcy. That said, the best strategy is always to avoid technical debt as much as possible. Here are six ways of doing that.
I. Have a clear initial technical strategy: Before the development begins, it’s important to think through all the critical technical details involved – what key decisions do you have to make? What will have to be added in the future? What functionalities you are dealing with? Do you have a clear acceptance criteria for all the features in the product? Having these things sorted before you implement the solution gives you a clearer roadmap. This way, you limit rework down the line.
II. Assign the project to an architecture owner: In an agile team, the architecture (AO) is responsible for guiding everyone through important technical decisions. In addition, she also trains and mentors members in design skills to avoid technical debt. Finally, she keeps an eye out for technical debt and takes immediate steps to address it when appropriate.
III. Refactor the debt: Refactoring is not to be confused with a complete rewriting of the code. It’s more to do with restructuring it without changing the functionality of the product. A few benefits would include, it makes the names more meaningful, reduces complexity by adding methods, and removes duplicate code. These changes are typically small and should be included as part of everyday development.
IV. Automate Regression Testing: Run comprehensive regression testing regularly. By doing so you can identify any defects that have been injected in the code, which gives you the luxury of fixing the code or making changes early on. Also, it would be advisable to automate the testing process to reduce human error and eliminate additional sources of technical debt.
V. Improve Test Coverage: Test coverage has always been a tricky subject. Do not limit testing to just lines of code. Extend it to the branches that occur in the logical use of the code. However, since test coverage is expensive, it’s important to test the product the way it will be used. Focus on improving test coverage beyond the usual tool calculated methods and metrics and focus on how your audience will use and interact with the product.
VI. Rewrite code when necessary: Sometimes, it might be necessary to rewrite code at the module level or package level. Is it a dangerous move? Yes. But this can help reduce overall technical debt. To be honest, it’s a judgment call that you have to take after evaluating the situation you are in.
For every $1 you earn by taking short cuts to release the product quickly, the compound interest on that debt could cost $4! So beware of incurring too much technical debt.
Want to learn more about managing software development? Contact VenturePact right away!
[hs_action id=”5891″]
