Decoding Technical Debt - Deciphering Definition and Exploring Causes.

Debt: Long before fully grasping the concept, we have been acquainted with its essence. From asking for a little extra pocket money from Mom to borrowing cash from friends, and eventually securing our first loan from the bank (with a promise to repay it with interest), we have all experienced debt. Translating this concept to the software realm, Ward Cunningham introduced a metaphor - 'Technical debt' - to explain the refactoring process he was undertaking for a company. Technical debt, like financial debt, comprises two elements: the principal (money borrowed) and the interest.

Let's dive into Cunningham's 2009 video and closely examine his explanation of technical debt (remember, technical debt is merely a metaphor!):

Borrowing money: The act of rushing the software out the door to gain practical experience.

Principal repayment: Engaging in software refactoring.

Paying interest: Enduring slow speed due to complexity.

Never repaying the borrowed money: Neglecting to incorporate the lessons learned back into the software.?

Ward in his experience report for OOPSLA 1992 wrote

“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.”

When comparing a financial debt versus a no-debt scenario, the presence of the former expedites the achievement of goals. Also, regular payment of EMIs reduces the financial burden on oneself. On the other hand, opting for a debt-free life may cause delays in meeting goal deadlines and one may need to abandon some goals.

Similarly, in the context of technical debt, it is important to understand that a certain amount of technical debt is necessary to speed up the delivery process. By engaging in periodic refactoring (principal repayment), the accumulation of interest is reduced, resulting in less interest payment.

An example:

By observing the graph above, you can note the following:

• Company X's excessive focus on perfect architecture and over-engineering hinders development speed and agility, leading to a loss of competitive advantage and potential business failure.
• Company Y's continuous feature additions without addressing a weak codebase results in accumulating technical debt, hampering growth and providing competitors an edge.
• Company Z effectively manages technical debt by regularly refactoring code, enabling scalability during rapid growth.

In the example above, the goal of any organization's tech is to emulate company Z, and the objective of this series is to comprehend and implement the necessary steps to achieve that goal. However, tech debt is an inevitable aspect of every company, and if not managed effectively, the company runs the risk of falling into the category of company Y.

Every software system is susceptible to the accumulation of cruft, which can make the addition of new features or the modification of existing ones more challenging and time-consuming, even when attempting to improve performance. This accumulation of cruft leads to technical debt. In the next installment of the tech debt series, we will delve deeper into the topic of cruft.

Now, let's explore the causes of rising cruft accumulation (and thus, rising technical debt).

There are numerous reasons for technical debt as outlined by Wikipedia, and I will discuss a few of them here.

Common causes of technical debt:

1. Business Pressure: Rushing software development leads to suboptimal code.
2. Inadequate Planning: Poor planning causes technical debt and future modifications.
3. Lack of Documentation: Insufficient or absent documentation hampers code understanding and maintenance.
4. Insufficient Testing: Skipping or limited testing results in undetected bugs.
5. Inadequate Skill or Knowledge: Lack of expertise leads to inelegant code.
6. Dependencies and Legacy Systems: Outdated systems hinder software updates and maintenance.
7. Scope Creep: Frequent requirement changes result in rushed implementation.
8. Lack of Collaboration and Communication: Poor teamwork leads to code inconsistencies and missed opportunities.

Unless identified?and addressed these causes can interact and compound, resulting in a higher accumulation of technical debt.

Almost all businesses are dependent on software systems directly or indirectly to thrive. Hence, it is of utmost important to maintain the delicate balance between innovation, business goals and code quality for long term stability, sustainability and growth. Gartner predicts, “Through 2023, I&O leaders who actively manage and reduce technical debt will achieve at least 50% faster service delivery times to the business.” Weaker code quality leads to the accumulation of technical debt, hence arising the need to prioritize, manage, and reduce technical debt over time.

In the next installment, we are going to talk about?benefits, cruft, types of tech debt and much more.

#software #tech #technicaldebt #longterm #business #code #quality #balance #softwareissues #debt #refactoring #cost #financialburden #cruft #scopecreep #outdateddocumentation #doc #legacy #dependencies #system #testing #interest #collaboration #communication