I recently heard the term tech debt for the first time and wondered what it meant. A brief search engine query provided the shocking information that this term was first coined in 1992 by Ward Cunningham, a developer who developed Wiki software. According to him, the concept of technical debt, or simply tech debt, can be described as:
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. Objects make the cost of this transaction tolerable. 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.
In other words, a debt is created when a developer (or development team) prioritizes fast development over quality code, resulting in costly operational errors. Thus, it is considered debt due to technology. I remember a particular incident where critical business operations were halted for more than 40 minutes due to a small programming error. When the root cause was identified, the program developer casually dismissed it as a typo, explaining that they had inputted a single equal sign (=) when 2 were needed. While this may have seemed insignificant, the entire meaning of execution was changed from comparing 2 variables to assigning the value of 1 variable to another. It is no wonder that the program behaved erratically, halting operations. The result was a significant financial and reputational loss for the organization. When the question of why the error was not detected during testing and peer reviews was raised, its answer presented the main cause of tech debt: “We had to speed up testing due to the preannounced go-live plan.”
Although rushed testing is not the only cause of tech debt, it is one of the most common. It is a fact that when one wishes to cut down the cost and/or time constraints of a project, the third constraint—quality—is the first to go. In the case of IT projects, testing is essential to minimize errors and fix operations bugs. It is well established that the cost of fixing bugs in a live system is much higher than it would be to invest in proper testing before going live.
Although the concept has existed for almost 3 decades, still organizations incur tech debts. Apart from saving costs (at the expense of quality), reasons for this include:
- Ongoing development to enhance functionalities over time makes the software complex and less efficient, requiring excess maintenance efforts
- Insufficient definition of requirements, causing scope creep during development
- Development that starts before a design is complete to speed up the project and meet tight deadlines
- Competitive environments that push an organization to attempt to release a product before the necessary testing is complete. Many times, negative testing (i.e., testing to ensure that the product is not doing something that it is not supposed to do) is neglected
- Enterprises that decide on an arbitrary go-live date without considering the implications
- Complex software with tightly coupled components (i.e., the software is not flexible enough to adapt to changes in requirements)
- Absence of complete test data needed to test all possible combinations
- Absence of or incomplete documentation resulting in delayed maintenance and change management
- Lack of appropriately skilled developers/technical staff for implementation and operations and/or lack of sufficient training
- Parallel development using multiple teams without efficient and effective coordination among them
- Absence of IT governance due to senior management and boards of directors (BoDs) lacking knowledge about IT requirements
In the early days of my career, my supervisor would say, “Try to make it right the first time.” That axiom also applies as a strategy to ensure that an enterprise is not incurring tech debt. Several actions aid in implementing this strategy:
- Include the risk associated with speeding up go-live as part of the project’s scope
- Build awareness among decisionmakers to inform them about the servicing of technical debt
- Increase awareness of project teams about the issues identified herein and address them proactively
Considering that handling tech debt only after go-live would be more expensive, it is best for organizations to proactively address any issues by taking the actions outlined when initiating a project or implementing new technology solutions.
Sunil Bakshi, CISA, CRISC, CISM, CGEIT, ABCI, AMIIB, BS 25999 LI, CEH, CISSP, ISO 27001 LA, MCA, PMP, is a consultant and trainer in IT governance and information security.