Technical Debt: How Does It Impact My Organization?
What is technical debt? Simply put, technical debt is software code that may not be quite as good as it could be. Although it passes quality assurance with no issues and works as designed, with possibly some edge case issues to later be discovered in production, the technical vulnerabilities begin to add a little more interest. Like any debt, if left unchecked, it tends to accumulate over time, thus compounding itself. Before long, the interest payment becomes increasingly taxing on an organization and an expensive pursuit to maintain.
This seemingly working code is known to need just a little bit more scrutiny. Usually, it is decided that this effort will be deferred to a later date when there is more time, but that time never materializes as it subordinates to higher priorities.
How technical debt happens
There are many reasons why technical debt is manifested and sometimes thrives like weeds in a garden. Even with the best intentions and discerning eye, technical debt can and does infiltrate a good design and well-thought implementations. Often, technical debt results from pressure to deliver by a due date. Adding this constraint to the development process causes shortcuts and intentional overlooks to improve the code base. Eventually, this practice leads to “patching” the code instead of the more time-consuming introspection needed to identify the deeper issues within the technical mechanics to gain the desired results of meeting a deadline. For the non-technical people, heroes are made as they can quickly implement new code and resolve problems by this error-prone patching method. This is one area that contributes to large, compounding technical debt because the deeper issues are not addressed and the code base gets increasingly more complex and fragile with each “patch”, eventually becoming a nightmare to maintain.
Similar to bad “patching” processes, technical debt can be the outcome of unnecessarily complex logic. Developers may not fully understand the scope of the task at hand. This “piecemeal” understanding is reflected in “piecemeal” code that becomes very unwieldy and difficult to understand by anyone other than the original author. Speed of delivery for future enhancements or bug fixes is drastically reduced as result of this form of technical debt.
Other sources of technical debt come from the fact that technology is continuously evolving. Organizations that wisely shy away from always wanting the latest and greatest tech stack eventually and sometimes suddenly discover that what they thought was a cutting-edge technology stack is outdated. Organizations often delay the decision to progress the path of newer and better until there is undeniably no choice. The result of this delay can bear an exorbitant cost burden and may even risk the company’s position in the marketplace.
What happens if it is ignored?
These are but a few sources of technical debt, with each causing increasing delay, complexity, risk, and compromises to quality. If not addressed, technical debt can adversely affect the bottom line and eventually preclude them from a competitive marketplace. Fortunately, there are ways to deal with technical debt before the final grim chapter of an organization’s demise.
A good first step
The first step to this effort is understanding where and how much technical debt is currently in the product. Ask and listen to the development teams by conducting a technical debt retrospective. This is a great exercise conducted by developers that helps identify areas in the product where technical debt exists. Basically, developers individually add sticky notes on a quadrant divided by effort (large/small) and impact (large/small). The outcome of this exercise is then added to the team’s daily work and planned accordingly. Bear in mind that eliminating certain technical debt is not worth the effort whereby organizational collaboration is critical in deciding to pursue or not. A distinguishing characteristic of companies that have a good handle on technical debt is their strong commitment to technical excellence. The driving force behind this commitment is rooted in the conviction that refactoring and addressing technical debt is part of daily work.
Conclusion
Companies that have acknowledged and pursued the reduction of technical debt have enjoyed better freedom of movement in how quickly they can deliver value, adapt rapidly to changing demands of the marketplace, and generally have happier customers. They are not burdened with delay, compromises to quality or outdated technology that befall an organization that ignores the debt interest that continues to add up.