When does technical debt stop being okay, and what to do about it?
Technical debt, like any other debt, requires a payback.
What is technical debt?
Imagine you researched and decided to be a video content creator and earn money out of it. First, of course, you would want good video editing software and a laptop to work on your video editing skills and the actual content.
You would want to buy the laptop as soon as possible to reap the benefits of learning more by buying early, instead of waiting until you have that much money, and then buying the laptop. If you wait, you'll miss the opportunity to learn and get into the skill/job market fast.
So what do you do? You use your credit card and buy the laptop on credit. You get into debt. Which you eventually will have to pay. :)
Technical debt, just like a credit card/loan debt, has to be paid. But here's where it gets tricky. While there is a bank that gets after you in case of a credit card debt, it's all you in case of technical debt. Nobody goes after you to clean it. This makes it difficult, and you can see codes after codes lying around in such debts collapsing at scale.
Remember that debt of any kind needs to be repaid, and so does the technical one.
Another point to note is that ignorance of good software practices and better architecture and creating a mess is not a debt. A mess is, well, just a mess. Here is a lovely article about it. Do read it to know more about this.
Moving on,
You cannot be agile without embracing technical debt.
Product teams often have two choices, ship or sink. Product teams usually accept technical debt as part of the process to reach the markets faster and get better feedback on their products.
Technical debt is an inevitable truth in a fast-paced startup.
Technical Debts are not at all a bad thing if it's taken with the right intent with a proper rationale behind it and by understanding the tradeoffs of the process. Business people and the product team must be on the same page that choosing technical debt for a faster Go-To-Market (GTM) will eventually require the development team to come back and refactor the codes, infra, etc. after the feature/product is shipped.
So the real question is:
When does a technical debt stop getting okay, and what to do about it?
Let's answer this with a few points to make a case:
ONE: When you try to go to the market all the time
Whenever a product feature is shipped, you start working on the next deliverable of the product, keeping the team tight on bandwidth and low on energy. Unfortunately, this does not give teams enough time to come back and solve or refactor.
What to do?
Give your product team breathers between releases, allow them to stabilize the just-released. Make sure the stabilization process in your organization has a clearing the debt activity as well. Don't wait too long for these stages, as the older a tech debt gets; it's more difficult and painful to refactor due to new features being made and new dependencies being created.
In short, "You cannot go to the market all the time."
TWO: When it becomes a habit, teams get comfortable not knowing what comes at scale.
As I said above, if you wait too long or don't give your team enough time to clear the debt, it becomes a habit, and I'm sure you know the power of habits. Your debt will be so large that it would require more than refactoring and, more than often, a complete rewrite of the codes.
What to do?
Teams comfortable with technical debt have a pattern. Watch out for these patterns. They either take shorter unoptimized methods to achieve a task that seems trivial, or they mostly depend on workarounds. You'll find these approaches during your code reviews, task plannings (sprint planning or backlog refinement in case of scrum teams), etc.
Make a process to ensure code quality in your organization and hold your team accountable to it (empathically, of course, 😛). Make sure most team members know the repercussions of using a substandard workaround. Make sure they are also aware of the tradeoffs by including them in the decision-making process.
💡 Pro Tip 1: Always maintain a list or a Debt Backlog, and whenever taking a call to do a workaround, take a shortcut, or introduce a debt in favor of faster GTM, update that backlog. Treat that backlog as one of the contributors to your task going ahead. Make sure that the debt backlog is updated, refined (estimated, budgeted), and prioritized just like the other product backlogs. Treat it with respect and as a first-class citizen, and you are mostly sorted.
THREE: Understanding that you might need to refactor
This is actually one of the basic things required when deciding the tradeoff in favor of a faster GTM with tech debt. With business priorities involved, it's very important for the business, as well as the product teams, to be very careful, align, and accept the fact that after the feature is shipped, teams will come back and refactor for the debt they created on the way.
This is just a very essential mindset alignment and nothing else. I've seen several businesses fail because of this.
What to do?
Educate each other about the tradeoff and pros and cons. Take the call keeping the refactoring time in mind. You can go to market fast, reap the benefits and allow the team time to make things right by paying the debt off. It's a win-win for all. 🥳
FOUR: When we are developing for something already a scale
I rarely see people talking about it. When you have things running at scale, giving in to urges to change a few things, or add a few things quickly must be dealt with care. More often than not, you'll make a workaround in a system that is already running fine at scale and had already been taken care of by executing whatever debt clearing process you might have had.
What to do?
Don't do it. Just don't. When a person who does not understand technology comes to you and says to "quickly" make some changes to a feature or system already running at scale, say a "no". Don't say no to the feature, say a no to the word "quickly" :)
💡 Pro Tip 2: Anticipate such requests, make sure that your system design/ architecture is inclusive to such dynamic elements in your organization. Remember even an excellent architecture can fail in an organization not ready for it. In the end, things are people-driven. So make sure your architecture supports such things.
💡 Pro Tip 3: Educate your stakeholders and other team members around the process of software development so that they are aware of tradeoffs and are able to judge the cost of the requests, themselves.
FIVE: When you don't pay attention to your architecture
When your technical debt is the result of a not-so-good architecture or system design, then it stops being okay to be in that debt. You can never get rid of such debts. You write awesome and beautiful codes but eventually, your architecture creates a bottleneck to scale and hence creates a debt.
The solution you ask?
Well, that's not the real Ted Mosby, but you get the gist, right? 😃
What to do?
Get your foundation in place, scalable systems are built over wonderfully laid out and well thought of architecture. Remember it's really difficult to refactor if your architecture is not right for the problem you are solving. So good amount of quality time has to be given to architect your system for your use case or product.
So all in all, architect your system well. Understand all the moving components of your final product, anticipate the scale well, and lay down a flexible foundation.
💡 Pro Tip 4: If you want to know more about architecting a web app I found this course very intuitive. Don't worry, I've not taken money for recommending this course. 😛
Conclusion
All said and done, romancing with technical debt is not a bad idea in order to go to market early and reap the benefits. But, we must be very careful and aware of our choices and must know the reason for choosing one over the other. If the debt is chosen, we must pay it back with grace.
Choose wisely. Cheers! 🥂
