This mini-series will focus on the issues that create poor quality software, one of which is technical debt. If you are not paying any attention to technical debt, then you are basically flushing money down the toilet. Technical debt is a concept coined by Ward Cunningham to describe coding problems that hinder product development. It refers to all problems and consequences that are associated with poorly written code. Businesses need to focus and understand technical debt to control their cost of poor-quality software.
CAST estimates that the Technical Debt of an average-sized application of 300,000 lines of code (LOC) is $1,083,000. This represents an average Technical Debt of $3.61 per LOC; and that is just the principal owed -CISQ
The easiest way to explain technical debt is defining it as coding that developers must do later because they took a shortcut to deliver the software as rapidly as possible. When developers add new functionalities to their software, they are presented with two options. They can take the ‘shortcut’ which can be messier and less integrated code but gets them to the software functionality faster. The second option is the ‘long’ way round which is code that is cleaner and more well designed but takes more time.
Technical debt is a lot like monetary debt in that it can gain ‘interest’ over time. With technical debt, interest is gained by the increasing difficulty of implementing changes later on, especially if a project goes through multiple phases. If it is ignored, the interest grows and grows. Recognizing this is a key starting point in reducing the technical debt associated with your project.
Distinguishing the different types of technical debt can help in understanding how to solve the issue. By categorizing tech debt, you will be able to provide an accurate analysis and estimation of the technical debt that has accrued.
There are different theorizations of the types of technical debt. Steve McConnell in 2007 hypothesized that there are two types of debt: intentional and unintentional. In 2009, Martin Fowler expanded upon it to create the “Technical Debt Quadrant”. This was based on if the debt was deliberate or inadvertent. Knowing these types can help you understand which path to pursue during product development.
Intentional tech debt is where the developers have decided that the technical debt is worth the risk to put their software product on the market. This is acceptable behavior if the monitoring of this technical debt is logged and watched from the time of implementation.
Developers need to consider the opportunity cost that is associated with incurring this technical debt. They need to ask themselves future questions about the product and the workload. By asking these questions, they can understand if the benefits outweigh the risks. If it is worth the risk, then this technical debt needs to be backlogged, tracked and repaid. Otherwise, you run the risk of creating future burdens for the development team.
Unintentional technical debt comes from bugs and a lack of attention or focus from developers. The bugs/issues continue to build and so does the debt. This perpetuates a huge threat to the software product and thus your business.
While developers might approach the design carefully and with a lot of thought, it is still a learning process. The functionalities of the product can be implemented, and it is only after implementation that developers realize they could have designed the components of the application better.
Development teams bring this debt upon themselves when there is no choice left and have no way to know when the debt started or how to eliminate the existing debt. They should stop and see if they can improve upon this debt and if it is worth the risk increasing the accidental tech debt or to backtrack their work to fix the issue.
Technical debt has a very real cost and impact on businesses. It can cause major disruptions and delays.
CAST bases the Technical Debt calculation in an application as the cost of fixing the structural quality problems in an application that, if left unfixed, put the business at serious risk. -CISQ
According to CAST, their estimate is that the technical debt for an average-sized application with 300,000 lines of code is $1,083,000. That means for each line of code, there is an average technical debt of $3.61. This increases with Java applications.
There is constant pressure on CEOs and CTOs to have their products perform as perfectly as possible. They are constantly running into time constraints. This induces pressure to cut corners and speed the development along.
Cutting corners and increasing speed becomes problematic when the product systems gain new features and grow more complex. Feature technologies that are not integrated or that do not work well together can lead to complex bugs and issues down the road. This results in the developers having to return to past issues instead of pushing forward new functions. The longer an issue is unresolved, the higher the probability of it becoming a large-scale problem.
If you allow technical debt to continue to exist in your code, this will be the architecture for all future code. There are some very real costs of technical debt besides just putting the business at risk. There is an impact on the velocity of product development, a very high chance of poor-quality software, less value delivered to the customers, and lower team morale.
When facing technical debt, you must understand where it originates from. The first step is to figure out what type and how much technical debt you ‘owe’. Take a look at the entire software development lifecycle and figure out where the technical debt is causing the most expense. Prioritize these issues.
The next step is deciding what to do. Take an in-depth look at your technical debt and decide which option to take. For some debts, it might be best to do nothing. For others, it might be scrapping the entire project and starting again. You need to pay back or reduce the debt at some point. It is up to you to decide whether it needs to be accomplished immediately or over time.
Going forward, you need to have an action plan of how you are going to measure your technical debt. Technical debt is measurable, although the system measurements differ from company to company. Some ways might include maintaining a debt list with a tracking system that then generates an estimated effort and schedule. A backlog can be created and issues that remain on there for a certain amount of time can be deemed as critical. Incorporate structural quality metrics to measure the design and construction of the system. Regardless of what the metrics system looks like, there needs to be one.
Technical debt is a complex and never-ending component of software development. There is no escape from it. However, being conscientious and selective in your technical debt is a strong display of strength. This will enable you to produce high-quality software instead of being bogged down with never-ending problems and debt resulting in poor-quality software.
%20(1).svg)