In simple terms, technical debt is the work that you’ve been putting off that is needed in order to complete a job. In other words if you find yourself cutting corners and saying you’ll get back to it later, you are taking on technical debt and should have a plan to manage it. If you are not consciously taking on technical debt (meaning you have to make an active choice to cut corners) and managing it, then it will get out of hand and make changing your code difficult and expensive.
When faced with certain constraints in the development process you may make the conscious decision to take on technical debt. This is not in itself a bad practice; as with any other type of loan, technical debt compounds over time and will become a problem only if you don’t stick to a strict repayment schedule. It is important to highlight to conditionality under which technical debt becomes problematic, because when it is well managed it can be a highly useful and effective tool.
One of the main components of managing technical debt properly comes from the ability to identify it. Technical debt is meant to be a temporary compromise in the evolution of your product’s software architecture or developer objectives – this could mean leaving some work incomplete such as:
Committing code without proper annotations: leaving code without annotations makes it increasingly difficult for anyone else to debug or change your code without having to piece together your original thought process.
Keeping a list of defects that continually go unfixed.
Settling for a poor automated testing that will eventually lead to having to write costly manual tests.
Using outdated, unsupported, or deprecated technology: either for efficiency reasons or simply because you are familiar with it*.
*While this can be a source of technical debt it is not a decision that usually involves software development teams. For the purpose of this post we will focus on technical debt which has been incurred by conscious decisions made by software development teams.
There are always constraints in play when you take on any form of debt. For example, you may not have enough money to buy a house or you may want to speedily close the transaction, so you go to a bank and take out a loan. When you take out a loan like this you understand that you will need to plan on how to pay it back.
The same is true in software development.
You may be facing deadlines to get a minimum viable product to market, to meet customer commitments, or you may have a temporary cashflow issue – as long as product management and developers are on the same page it is okay to take on some technical debt. However, you should always do a risk/impact assessment and be fully aware of what this approach entails. When you take on technical debt you should be making the commitment to pay back the debt at a later date.
There are consequences to not paying back technical debt, just as there are consequences to not paying back a bank loan.
For example, if a team didn’t put in the appropriate amount of code annotations or testing automation by a certain deadline, then later done line when a developer who must maintain it and but wasn’t the one to create the particular module will have difficulty doing their job. This can even occur to the initial developers who want to maintain their code and may not remember how or why things were done a certain way. Therefore, they will have to manually test their changes, which is costly, and may only be able to complete partial testing. Meanwhile, paying customers will be using the software that isn’t being maintained properly.
A situation like this will lead to the following consequences:
Slower delivery: as the business and its usage grows the cost of adapting to demands will increase dramatically and poorly maintained code is difficult to continue developing. This will lead to longer development, testing, and deployment cycles.
Higher risk: once software is in production any change can have a negative effect on your customers’ experience and your business’ success.
Lower quality: with gaps in documentation and test coverage in combination with time and customer pressures, your software quality will inevitably be at risk.
These are serious consequences to contend with, so if you’re going to take on technical debt you need to be aware of what that decision comes along with and manage it properly. When you adequately manage a financial loan you minimize interest payments, the same goes for technical debt management.
This means focusing on the following dimensions:
People: enacting a culture of accountability and responsibility across various teams will create organizational awareness on technical debt and create a constant reminder of where you have technical debt and how you are planning to deal with it.
Processes: making a habit of adding any incomplete work to a backlog as soon as they become apparent will create visibility and discipline with handling your debt. It will also ease prioritization of what issues are the most critical to your software.
Technology: having tools that enable visibility and control over how you manage technical debt can only have positive impact on your development process. This could mean using a reporting system that shows code test coverage and other technical debt related tasks.
Technical debt management cannot be conquered in one sitting, it is a continual effort that requires the entire team’s participation. If you are doing things right, you should be able to make an informed decision on whether or not going into technical debt is worth it or not.
To read the full post visit here.