Technical debt is inevitable. We always have it around. Yet, we can keep it as low as possible especially when we work in startups or projects with tight schedules. After all, technical debt has a direct impact on the business goals and performance. Special we would expect fast delivery in major products with high competition or in startups with delimited resources. It is so common to neglect technical debt. As if it was not there at all. However, we know that we will reach the point which we have to pay back. Do not get me wrong here. Having a technical debt isn't bad. The issue here is not looking at it the right way. In fact, ignoring it.
Here I introduce some of my observations and personal experience on dealing with technical debt. I do not want this blog to be long. Rather I want to graze over the topic.
Understand the debt you need to pay back
Not every issue, bug, or improvement should be and can be handled. Instead, try to prioritize them around business needs, the impact they make, and the amount of work they need. For example, changing a message broker in the system is a technical debt. However, we can ask if we can delay it for a month, three months, or even six months. The main concern is to see debt and decide when and how to address it.Understand the business domain:
As technical people, sometimes we forget why we are creating software or pieces of functionality. This can lead to two things. One is the stream of tasks and requests from the other teams, and the second is the contrary. Working on a component for a long time and keeping everyone waiting. By understanding the business you can negotiate with managers and feature-hungry domains within the organization
For example in a trading system, the client asks for a feature for buying options. Without knowing about the business and its criticality you can not decide whether to keep it for the future or deliver it very fast.-
Categorize the debt and decide which one is a do-or-die
I use the Reforg blog as a reference to types of debt, however, you can modify them any way you want.
The 6 key types of technical debt that teams encounter are:- Stability debt
- Security debt
- Maintenance debt
- Developer efficiency debt
- Technical product debt
- Decision debt Now based on the categories mentioned decide if the technical debt is a priority or not. For example, you know there is governance regulation imposed regarding the security. So If you have to fix a security or you have to work on database stability, for example, you need to do the security patch first. It sounds no-brainer, nonetheless, in a day-to-day job if do not have a clear categorization, you or your managers may miss the debt.
Zoom out and focus on software architecture early on
A good architecture can reduce many stability, maintenance, deployability, and flexibility issues. As a result, you may face nominal debts. For example, changing from cloud to in-house servers can be costly. So we can work more on such decisions. We must keep in mind that, we may start simple and later expand the work as per our need. For example, there is nothing wrong if we do not start with domain domain-driven design or CQRS pattern. But it is important to know 6 months or one year from now what we should expect. If you are planning to move into microservice, you must plan early. Even a mature startup company may overhaul its architecture to answer new business challenges. This kind of technical debt is always present itself while your system grows. The important point is how prepared we will be to tackle the challenge.Setup a Continuous Integration and Testing
When it comes to handling technical debt, continuous integration and testing are like superheroes for developers. They act as a shield against accumulating technical issues. Imagine automated testing as your trusty sidekick in CI/CD pipeline—detecting and fixing problems early on and ensuring new changes blend seamlessly with existing code. This dynamic duo not only prevents the growth of technical debt but also boosts the overall stability and reliability of our software. By giving importance to continuous integration and testing, teams can create a culture of quality assurance, keeping projects on track and avoiding long-term headaches.
I hope you take some points from my experience. Curious to know your thoughts. Please comment below on what you think about the technical dept.
Top comments (3)
In my experience, the worst part of technical debt is that it is a huge drag coefficient on developer productivity.
It turns a x10 team into a 10% team, and does so very quickly. The only reason a x10 team is considered mythical is because technical debt is commonplace and often ignored.
Shel Silverstein wrote a wonderful poem called Sarah Cynthia Sylvia Stout Would Not Take the Garbage Out which, as it so happens, also allegorically describes technical debt quite well.
No amount of testing can negate technical debt. The only viable solution for technical debt is to stop being so feature-hungry and put quality over quantity as a bussiness perspective.
Technical debt emerges when the bussiness has specific requirements and the developers have to cut corners to meet those requirements. Whether it’s code maintainability, architecture or even properly testing your product - technical debt always emerges when the business is unrealistic about it’s demands. The developers, who all would like to keep their jobs, must hack their way into a seemingly working product as fast as freakishly possible just for the sake of deploying a product.
Yes, that is what the business needs, or, that is what the investors like to hear. But in real life, many companies have closed their doors because of this attitude.
Bottom line is, we should not be thinking about creative ways to tackle technical debt, “go or die” as you say, it’s the opposite. We should be thinking about how to change the business perspective to prevent technical debt from the get go.
Thank you for taking the time to share Lev. It is an honor for me to have you read and comment.