Success Stories of managing and paying down Tech Debt

What is Technical Debt? Where does it come from?

Let me introduce this concept with the following example: Imagine you have a big homework assignment to do, and you have two options. The first option is to take your time and give it your best, ensuring everything is correct and well-organized. The second option is to do a rush job, cutting corners and not paying as much attention to lesser details.

If you choose the second option, you might finish the assignment faster, but you will probably also make mistakes, forget important information, or leave some parts unfinished. These mistakes and missing parts could cause you problems later, such as losing points on your assignment, causing it not to work or potentially requiring you to need to redo parts of it, likely in the long term leading you to need more time to do the work then if you had done it right the first time.

Technical debt is the second option for software developers. Sometimes they have to rush to finish a project quickly, and they might cut corners or make short-sighted decisions that they know are not the best solution. This can save time in the short term, but it can create problems in the long term, such as bugs, crashes, or difficult-to-maintain code.

The concept of technical debt was introduced by Ward Cunningham, a software developer and wiki inventor. He first used the term in a 1992 email to a colleague, in which he compared the costs of software development to financial debt:

"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. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Whole engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation."

In other words, Cunningham explained that technical debt results from making trade-offs between short-term gains and long-term consequences. Just like taking on debt in finance can provide benefits in the short term but come with interest payments and other costs, taking shortcuts in software development can provide benefits in the short term but create costs and difficulties in the long term.

Success Stories

Carlos Fuentes: In the role of technical leader of a project, you should have a plan in place to manage the technical debt. In my experience, keeping a backlog of tasks related to the technical debt has been very helpful, and then ensuring that I communicate about it with the team, including stakeholders such as Project Managers, Business Analysts, Developers, and other tech leads, to identify which of these tasks are higher priority to get scheduled sooner in a future Sprints. Once visible and manageable, and in accordance with the number of developers available in that team, the technical debt can then be paid progressively. A good goal is to include one or two technical debt tasks per Sprint.

Roberto Cordova: There was a project where we reached the delivery deadline, but there were still many things that needed to be improved. We made an agreement with the client to create tickets in order to document and pay back this debt later on. As a result, part of the team's work each Sprint would be dedicated to tasks that would cover the remaining debt.  Eventually, we reached a point where many tasks were becoming obsolete due to the fact that new feature work had started to cover parts of the technical debt. This success story on a strategy for paying back the technical debt in our project as part of the workload during every Sprint became a vital part of the team's synergy, especially once key stakeholders saw how well it worked out.

Managing the tech debt.

Managing technical debt involves identifying, prioritizing, and repaying the debt over time in order to maintain the quality, reliability, and maintainability of the software. Here are some simple steps to  manage technical debt:

1. Identify: This involves recognizing areas of the codebase that are inefficient, difficult to maintain, or prone to errors. This can be done through code reviews, testing, and analysis of user feedback.
2. Prioritize: Once the technical debt has been identified, it's important to prioritize it based on its impact on the software and the business. Some technical debts may need to be repaid immediately, while other debts can be deferred or may never need to be repaid. 
3. Create a plan: This involves outlining specific steps needed to address the targeted technical debt, such as refactoring code, fixing bugs, or upgrading outdated technology. It's important to balance the need to repay technical debt with the need to deliver new features and functionality.
4. Monitor and measure progress: It's important to track progress in repaying technical debt and measure the impact on the software and the business. This can help to prioritize future work and ensure that technical debt does not accumulate over time.
5. Prevent future: To avoid accumulating new technical debt, it's important to establish coding standards, best practices, and processes for testing and quality assurance. This can help to ensure that new code is maintainable, reliable, and scalable over time.

The next image is commonly used to map and prioritize and establish a plan around the technical debt with the team where we can identify a task as Valuable or Difficult and prioritize the execution of these tasks:

As we mentioned, technical debt refers to the future cost that will be incurred by choosing a lower quality or faster-to-implement solution rather than choosing a higher quality or slower solution. In other words, it is the consequence of making decisions that may have a long-term negative impact on the development of a project or system.

There are situations where taking on technical debt may be an appropriate choice. Some of them are detailed below:

• Tight deadlines: If the project has a tight deadline, it may be necessary to assume technical debt temporarily to meet deadlines. In this case, the technical debt must be prioritized and managed appropriately so that it does not cause problems in the future.
• Quick innovation: If the project's objective is to innovate in a highly competitive market, it may be necessary to take on technical debt to be first to market. In this case, the technical debt must be carefully controlled so that it does not affect the quality of the final product.
• Proof of concept: If a new concept or technology is being tested, it may be necessary to take on technical debt for rapid testing. In this case, the technical debt must be carefully controlled so that it does not cause problems in the future.
• Prototypes: If a prototype is being built, it may be necessary to take on technical debt to do so quickly and validate the idea. In this case, the technical debt must be carefully controlled so that it does not cause problems in the future.

However, there are also disadvantages to assuming technical debt. Some of these include:

• Future costs: Technical debt increases the cost of maintaining and upgrading the system in the future. If technical debt is not managed properly, it can lead to significant costs in the future.
• Failure Risk: Technical debt increases the risk of system failure in the future. If technical debt is not properly managed, it can lead to significant failures in the future.
• Difficulty in changing: Technical debt can make the system more difficult to change or upgrade in the future. If technical debt is not properly managed, it can lead to a loss of flexibility in the system in the future.
• Impact on quality: Technical debt can decrease the quality of the final product. If technical debt is not managed properly, it can lead to a lower-quality end product.

These success stories show that with the right approach and mindset, managing and paying down tech debt can significantly impact a company's bottom line. By investing in their team, prioritizing modern technology, and careful planning, companies can achieve a more efficient and effective codebase, increasing productivity, revenue, and customer satisfaction.