What is Technical Debt in Software Development?
This post is intended for non-technical business owners. Although business owners themselves do not code software, we at Hireplicity believe that they deserve transparency in the building of their software product. This transparency empowers them to make more informed decisions about their custom software development.
What is technical debt?
Technical debt is sub-optimal code, software design, or human resources. Technical debt arises from a need to deliver software fast, which may necessitate compromising on other factors of software development. It opens an opportunity to speed up development. But it can cause problems down the road.
Technical debt is a metaphor. Like financial debt, it can accelerate growth but it has to be paid sooner or later.
Different people can have different opinions on technical debt. People on the technical team may prefer to have zero of it; while business executives may understand that it can be necessary when it is a "ship or sink" situation.
What are the different types of technical debt?
Architecture Debt. This refers to a sub-optimal design of the structures of a software system. For example, a team may choose a solution that has more dependencies to ship faster.
Build Debt. These are code written in a way that is hard to add more functionalities or features. It can also refer to code that does not add value to the customer but is written so that a piece of software can operate.
Code Debt. This is code within the source code that is difficult to read or understand. Code debt makes it difficult to update or maintain a piece of software. This is caused by poor coding practices and a lack of refactoring.
Defect Debt. This happens when fixing a known bug is delayed.
Design Debt. Software design principles are violated in favor of a faster solution.
Documentation Debt. Documentation is skipped over to save time or money on labor. When the software becomes more complex or when a development team increases in number, the lack of documentation can become more problematic.
People Debt. This type of debt refers to the composition of a software development team. An example of this is where expertise is concentrated to only a few people, causing a project to be disproportionately impacted if one person leaves the company.
Process Debt. This happens when the process of building software does not fully meet project needs. However, development is continued to meet pressures such as deadlines.
Requirements Debt. A software requirement describes what a piece of software can do. Requirements debt happens when a development team is not able to fully meet software requirements, such a performance or security requirements.
Service Debt. This refers to a poor selection of web services. A web service is a resource that allows different software systems to interact over the Internet.
Test Automation Debt. This happens when there is insufficient test automation. Automating tests is necessary for faster software development.
Test Debt. This can mean many things. It can mean incomplete test coverage: writing tests that do not cover the entire software. It can also mean automated tests that are poorly designed for their target code. In some cases, it can mean poorly designed test cases. A well-designed test case is important in verifying that software performs as expected.
Usability debt. This refers to code that leads to bad or inconsistent usability. For example, a web app may contain an inconsistent tool layout.
Martin Fowler's Technical Debt Quadrant
Reckless and Deliberate: "We don't have time for design." This type of debt happens when a team is aware of better solutions but chooses to apply a "quick and dirty" fix.
Prudent and Deliberate: "We must ship now and deal with the consequences." This is incurred when a team makes a technical debt, is aware of it, and creates a plan to repay it in the immediate future. Prudent and deliberate debt is usually added to the backlog, to document it and create a deadline to fixing it.
Prudent and Inadvertent: "Now we know how we should have done it." This happens when a team ships a product with the best intention, only to find out later on what they could have done better. Prudent and inadvertent debt is common. Teams build a product better as they learn more about it.
Reckless and Inadvertent: "What's layering?" This is a technical debt that a team is not even aware they have incurred. This is where the line between ignorance and neglect becomes blurred. With so many technical problems that can arise in a software project, it is logical to assume that the technical team cannot know it all. But it is equally logical to assume that a software team should do their best to select solutions that they are most skilled at.
How does technical debt impact software?
Technical debt can have positive and negative effects on software development.
When used wisely, it can be a tool to navigate the constraints of software development--namely, costs and deadlines.
Positive impacts of technical debt
It can provide revenue from a timely shipped feature (that is potentially greater than the cost to repay it).
It can be a tool to meet time-bounded goals.
It can be a tool for short-term cost savings.
Negative impacts of technical debts.
Software takes longer to build because more time is spent dealing with bugs or poorly written code.
Software becomes more difficult to maintain. Technical debt makes it difficult to improve performance, correct defects, or adjust to new trends.
Teams suffer a decline in productivity. When a team is tasked to update a system with technical debts, they might spend a lot of time fixing the debts first before being able to get on with their work. An enhancement that should only take three weeks can easily roll into six weeks of toil.
Testing can become strained, especially when technical debts are not documented.
Software performance is volatile. An increase in traffic or minor tweaks to the system can severely impact software, which otherwise should not.
It restricts flexibility because some developers will be required to rework the debt.
Outages may be necessary when fixes to technical debt are implemented.
When is technical debt acceptable?
Technical debt should be considered a leverage to achieve goals. There should be a deliberate decision to incur technical debt and a clear strategy on how to resolve it.
Strategy. Business owners, product managers, and the technical team work together to decide which technical debt to acquire and how to repay those debts.
Rationality. The time-driven benefit is worth investing in more time and resources to pay that debt later on.
Intent. There is a clear reason why technical debt is incurred.
When is technical debt manageable?
Transparent: Teams are upfront about accruing technical debt and review it every sprint.
Tracked and documented: Bugs are analyzed with tools such as SQALE method, cyclomatic complexity, and code coverage.
Fixed every sprint cycle: Technical debts that come with a deadline are easier to manage. In every sprint cycle, a team can allocate 20% of their time fixing tech debt.
Included in the definition of "Done": A ticket should be moved to "Done" only when it falls below the threshold for technical debt.
Standardized procedures: In Agile development, technical debt happens routinely. Therefore, it makes sense to put in place a standard procedure on how to acquire and repay it.
Technical debt is a natural part of agile software development. It can be a tool or a threat. It comes down to how it is incurred and managed.
Do you have questions about how to strategically address technical debt in custom software development? Talk to our CTO today.
