Originally coined by software developer, Ward Cunningham, who was a co-author of the Agile Manifesto and also the developer of the world’s first wiki. His main purpose was to explain to non-technical stakeholders at WyCash the significance of refactoring and the need for resource planning and budget allocation for the same.
Technical Debt is a term used to describe the trade-off taken by the development teams such as short-term workarounds or poor design choices which do not adhere to the standard practices to meet the deadline.
Simply put, “technical debt is any code added now that will take more work to fix at a later time—typically with the purpose of achieving rapid gains.” It also includes deferred refactoring.
Such workarounds, shortcuts can be beneficial for the short term or achieving immediate goals. However, its accumulation over a long period of time may lead to complications in the development of new features and even making maintenance work more difficult or even go to the extent which may lead to retiring it in extreme cases.
Like financial debt, technical debt can be considered as two parts: principal and interest. In software terms, the interest can be associated with the additional work required to maintain the software system because of the substandard codebase. Refactoring the codebase without impacting the performance or existing functionality of the system represents paying down the principal on the debt.
Classification of Tech Debt
Technical Debt has been classified into 13 different types as per a paper(Towards an Ontology of Terms on Technical Debt) published by the Software Engineering Institute and they are as follows.
- Architecture Debt
- Build Debt
- Code Debt
- Defect Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
In 2007, Steve McConnell suggested that there are 2 types of technical debt: Intentional and Unintentional.
According to him, Intentional tech debt is one taken consciously as a strategic tool and Unintentional tech debt, which he calls “the non-strategic result of doing a poor job.”
A few years later, Martin Fowler took McConnell’s concept a step further and published what he calls the “Technical Debt Quadrant”. This quadrant attempts to categorise technical debt into 4 categories based on both intent and context.
Reckless Accidental: Those incurred due to ignorance for which the Ideal solution would be the team should stop and self-improve (through training, hiring, or whatever other means is available) such that it is able to at least recognise the kind of debt it is incurring currently.
Reckless Deliberate: This kind of debt occurs when a team knows better, but consciously chooses to make “quick and dirty” updates to a system, usually in the name of speed and hence it’s a kind of behavioural trait.
Prudent Deliberate: This represents quality shortcuts made consciously by the team because of an imminent deadline. The team recognizes the issue (and most likely adds correcting it to their backlog) and its consequences but must choose to deliver something rather than focus on quality at this time.
Prudent Accidental: This is something that was unintentionally missed during implementation but realised after evaluation accompanied with learning after the completion of the project.
The Way Forward: Reducing Technical Debt in New Initiatives
In order to reduce technical debt in new projects is to include technical debt in the conversion early on which will enable to account for the impact of short term decisions on long-term ROI and create a plan for paying off debt in the initial stages of development.
