Technical debt (TD) is the cost of additional work that arises because of prioritizing the speed of delivery of a piece of functionality in a system or project over accuracy. In many cases, shipping speedily results in the functionality requiring to be refactored later. Tackling technical debt in an organization’s system architecture is important because problems can cascade beyond the IT department and affect core operations such as shipping and order handling.
There are times when technical debt is acceptable. A development team can deliberately prioritize shipping a feature but schedule certain things for fixing after delivery. However, this requires proper tackling to ensure there are no resultant problems that negate the benefits of the initial speedy delivery. In many cases, though, technical debt is often a result of a lack of prudence or proper skills on the part of a team charged with delivering a software project.
Here are a few common ways that technical debt arises.
Sub-standard Code Quality
Bad-quality code is a major cause of technical debt in companies today. It may be that software developers are using complex tools with no business case when simpler tools would have been sufficient. In other cases, developers fail to include proper documentation for the code that they write. It then becomes difficult for them or other team members to maintain that code. Such a problem can become endemic within an organization where a proper documentation culture is not enforced.
Good practice requires that new team members receive proper training on the working methods and tools used to write code and build features. The lack of training can lead to incoherence and substandard code quality.
Complex Technical Designs
Another major cause of TD is overly technical designs. Such designs require very skilled software developers that will normally earn a premium for their skills. The development team can find itself strained for resources leading to shortcuts in implementing the designs. Complex designs also require experienced senior developers to lead teams and supervise code quality. Without such leadership, teams may end up shipping substandard features.
Lack of Sufficient Testing
Whenever development teams rush to beat short delivery deadlines, chances are that new features may not go through proper testing before being deployed. While they may work quite well initially, chances are that they will eventually need refactoring so that they work optimally.
Information Obscurity
There are situations where one developer withholds work-related information perhaps due to security reasons as stipulated in their job description. While such measures are sometimes necessary, a lack of information sharing might cause knowledge loss. To prevent this, a knowledge resource may need to be created even if it will not be shared with everyone in the company. Its existence may help the person that comes after the current team lead.
Technical Debt Quadrant
Martin Fowler, a public speaker on software development, says there are four technical debt categories. TD can be reckless, prudent, deliberate, or inadvertent, hence the quadrant.
Prudent and Deliberate
Prudent and deliberate technical debt arises when the team intentionally prioritizes speed with a view to paying off any technical debt later. Here, the risks must be low while the benefits of speed should outweigh such risks.
Reckless and Deliberate
Here, the team has the time to ensure perfect code but still prioritizes speed without regard for the risk. This obviously is bad technical debt.
Prudent and Inadvertent
Prudent and inadvertent technical debt arises when the team thinks they had shipped the best code at the first attempt, but they end up finding a better solution later. They then go through another iteration of the code to improve it.
Reckless and Inadvertent
This type of TD will arise when a team does not have the requisite skills and knowledge to deliver a project. They, therefore, end up making mistakes inadvertently. For instance, a team may build a website on a platform such as WordPress when another solution may have been suitable for the required functionalities.
Assessing the Technical Debt in Your Organization
It is important for any organization to keep good track of the amount of technical debt they are carrying. The first way to measure to track is when the development team knows the code is not clean yet deployed (prudent and deliberate debt). The next metric is the amount of code churn. This is the number of lines the team has to rewrite after deployment. A higher number of rewritten lines indicates a higher technical debt.
Companies should also keep track of their technical debt ratio. This is the cost of fixing bugs (remediation) compared to the initial development costs. If the remediation costs pile up too quickly, then it means the technical debt was too high, and perhaps the company needs to relook at their development practices.
Preventing Accumulation of Technical Debt
Certain best practices can help prevent a company from accumulating excess TD. The most basic practice is to keep a proper record of TD. You should also maintain records of all resolved matters so that there is transparency regarding pending cases.
The next arm of prevention is the hiring process. Companies should prioritize hiring experienced developers with a clear demonstration of handling complex projects. Such developers should be well anchored in development best practices such as project documentation.
Next, it is important for the company to come up with a way to categorize technical debt based on their cause, complexity, and time-to-fix. The company may also need to change the definition of what a completed task means so that they do not sacrifice accuracy for speed when the costs outweigh the benefits.
No company is ever fully free from technical debt. In fact, it’s important to encourage code refactoring to improve efficiency. The resolution of each piece of TD should be treated as its own mini-project covered in a single sprint to resolution. By handling technical debt effectively, the company can minimize project costs that arise after launch.
To learn more about technical debt, DevOps, and proper software development practices, visit our website. Transcendent Software is a full-fledged IT services company with over 10 years of experience in helping companies make the best of their IT infrastructure.