In software engineering and agile development, technical debt refers to debt incurred by the development team by choosing a quick fix or messy design at the expense of a better, possibly longer and harder approach. Just like financial debt in an organization, technical debt has to be repaid else the interest becomes so high that it starts slowing development and may result to buggy software. This article explored what contributes to technical debt and how to keep it at a minimum.
Technical debt can be categorized into either deliberate or accidental. The two categories will later inform if the debt is reckless or prudent. In the first part, debt is incurred deliberately and recklessly due to ignorance and often characterizes an undisciplined development team. It is deliberate and reckless for team to claim for example they don’t have time for design. On the other hand, a deliberate but prudently debt is incurred knowingly and is acknowledged with a predefined time for repayment. A good example is a where a bug has been discovered on a critical software already in the market. A team can issue a quick and dirty patch to the software and deal with the consequences of redesigning and issuing a better patch later. The second category is the accidental category. In this category teams incur debt accidentally either by being reckless or prudent. The notion here is developers keep learning while still writing production code. Debt in this category is incurred deliberate but because there is “lack of skill” to do something better.
While technical debt can be incurred in the every stage of software development cycle, it is mostly incurred during design, development and testing. Design phase is one critical part of software development life cycle. A good design results in smooth development resulting to better software. Teams however think there is no time for design or they can write code without having to design. This results to bad architectures, redundant code and buggy software. During development, teams sometimes choose quick fixes over better approaches to solving problems. Lastly testers might ignore minimum test coverage requirements or not perform all the required tests. All these contribute to technical debt.
Enterprises can minimize technical debt by ensuring development teams have sufficient and complete business requirements and definition before development cycles, processes are understood and adhered to, test suits are defined beforehand and adhered to during testing, collaboration between various subteams throughout the process and refactoring every iteration before moving to the next.