Everyone is always excited to work on a brand new project. A greenfield project allows developers to start from scratch, apply the lessons they learned from the past, and try to create a codebase that reflects high quality/low tech debt code.
But, frankly, every codebase, no matter the developer is going to succumb to some kind of tech debt at some point.
I thought it would be worthwhile to share my experiences with tech debt and what it takes to pay it down. Of course, there are more than two types of tech debt, but I think the two we talk about here cover a lot of ground.
Brief primer on technical debt
If you’re not familiar with technical debt it is similar in concept to your traditional debt. When we borrow money from a lender that money eventually needs to be paid back. Often times, the longer it takes to pay down that debt the more painful to your wallet it becomes.
Tech debt is the same concept, but with codebases rather than money.
When we are developing an application or service we make a series of decisions based on the knowledge we have at that point in time. These decisions could be influenced by the technology available to us. They could be made based on the amount of time we have to deliver something. Or they could be reflections of the current team at a certain skill level.
Each decision throughout the development process is reflected in the codebase. These decisions directly or indirectly can lead to what we call technical debt.
In essence, tech debt is the debt we accrue in our codebase because of the software development lifecycle we participate in. I like to think of tech debt in two separate categories, iterative development, and repetitive tasks.
Iterative development debt
In a perfect world software development would be flawless every single time regardless of the product or service being created. We would take a set of features that we know are exactly what a user wants, build them, ship them, and profit.
However, we don’t develop software in a perfect world.
We develop software with limited knowledge and therefore must develop features and entire applications or services iteratively. In fact, we embrace this method of development because it gives us the agility to revisit our decisions and make them better as we gain more information.
Often times we make decisions in an agile environment that we know may not be the best because they introduce technical debt. But, we make them anyway for a variety of reasons. These reasons vary from it’s the best we can do with what we know now, all the way to we are under a time crunch and must get this done.
Essentially, iterative development creates technical debt because we must make tradeoffs in order to complete something to take the next step forward.
This iterative development tech debt is often created knowingly by a development team. It is created with the best intentions and we as developers often want to revisit it in order to make it better.
When it comes to this type of debt there are some key things we can do in order to make sure we pay this down at some point in the future.
- Add
TODOcomments to the function(s) that we know need to be revisited based on tech debt. Then have a process to revisit these when working on a bug or new feature in this area. - If the tech debt was introduced by the development of an item in your backlog, add a follow-up item in the same backlog to revisit this in the future.
- Have regular tech debt prioritization meetings. Development is all about creating sustainable value for our end users, fixing/cleaning up tech debt is apart of sustainability.
Iterative development is about going fast and making decisions with the knowledge we have. We make the best decisions we can at that point. We may know that some of these decisions are less than ideal, but we make them anyways as it is what we have at the time.
This isn’t right or wrong, it’s normal. The key here is that we make a conscious decision to introduce this kind of tech debt. But, we must also have a plan in place to pay that debt down over time.
Repetitive task debt
Contrary to iterative development debt, repetitive task debt may sneak up on us. In other words, this type of tech debt may not be seen as debt initially.
So how do we spot repetitive task debt?
We look for the things that are slowing us down. Are there tasks that we are having to do manually more than 2-3 times a week? Are we having to answer the same question(s) over and over? Anything that is a repetitive task or workaround can be considered as tech debt.
The pain point here is that this type of debt creeps up on us because we are typically OK with doing something repetitive one or two times. However, these tasks become more frequent as the software evolves or the customer base grows.
We must keep track of this repetitive task work and eliminate the debt associated with it once we reach an uncomfortable threshold. To help eliminate repetitive task debt here are some things we can do and watch out for.
- Track the various manual tasks you or your team are having to do every week. If there are tasks that are having to be done daily, figure out a way to automate them or resolve the debt that is causing them.
- Separate repetitive tasks into workarounds and manual work. The former is often an indicator of iterative development tech debt that needs to be resolved. The latter is often a new feature that needs to be developed to support the sustainability of the product or service.
The key with repetitive task debt is to make it visible so that we prevent the creeping up effect. By tracking these type of tasks we can reveal the debt that we need to pay down in order to free ourselves up.
Conclusion
Technical debt, much like traditional debt, is both a positive and negative thing for us as developers. We can consciously choose to take on a certain level of debt in order to accelerate our development or create value with our current knowledge base. But, the debt must also be paid down over time or we run the risk of making our lives miserable.
Here we have explored two types of technical debt. Iterative development introduces debt because we make decisions based on limited knowledge or accept that a decision is less than ideal for the time being. This type of debt is introduced consciously, but we must have a plan in place to revisit and pay this backdown.
Repetitive tasks introduce their own tech debt and it often sneaks up on us. This type of debt could even be introduced by the other. To resolve this debt we must make this work visible so we can measure the pain we are feeling. This allows us to circle back and resolve the debt that is causing this pain.