Technical debt
Everyone has heard of this almost a buzz phrase - technical debt. But what does it really mean? Is it good or bad? Do you need to "pay it down"? The article from Stack Overflow gives a good overview of this topic with a checklist for tackling the technical debt in your company or project.
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.
In my personal view, technical debt is an issue in the code. You are aware of it, but keep avoiding finding a permanent fix; instead, you patch it with workarounds or temporary fixes.
Is it good or bad?
As I said earlier, technical debt is an issue, so I would rather put it in the category of things we would rather not have in our code.
But why is it bad? Because eventually, the technical debt will catch up to you when you least expect it. It often happens when you're close to completing a long-awaited feature but are unable to do so until you address the technical debt. If you haven't experienced this, ask your colleagues if they've ever been in similar situations. Perhaps technical debt is lurking just around the corner for you.
10 tips from Stack Overflow
Here is the checklist that is also available at Google Docs:
- Prioritize and triage critical areas of tech debt
- Refactor regularly
- Allocate time for tech debt repayment in sprints and regular workflows
- Automate (identify, track, fix) when possible
- Educate and share with your team
- Write clear documentation
- Adopt a “pay it forward” mentality
- Implement and participate in code reviews
- Test early and often
- Align with business objectives
Not all of the points above, e.g., "Test early and often", are specific for reducing and preventing technical debt but rather a best practices for any software engineer.
I cannot over-emphasize the importance of the following tips:
- Prioritize and triage critical areas of tech debt
- Refactor regularly
- Educate and share with your team
Prioritize and triage critical areas of tech debt
Yes, you heard it correctly, "triage" is the word used for technical debt. Not only do the bugs need to be triaged, but technical debt must also be addressed. Ultimately, the consequences of the untriaged technical debt might be much worse than the untriaged bug.
Refactor regularly
I'll repeat that clichéd "Boy Scout rule": "Always leave the campground cleaner than you found it." It is that simple. Every time you change the code, spend this extra time, which can be 5 minutes or a couple of hours, depending on your capacity, to improve something. If you don't know how to improve, check SonarQube to find smell codes, write unit tests, upgrade dependencies, or simplify the code. Anything would do. And believe me, there is always something to improve because "all code is technical debt" :D
Educate and share with your team
Many people like to be an army of one and want to change the world. Let's be realistic, though; the teamwork is essential. You can keep fixing and refactoring the code after yourself and your team. Still, the team would generate more than you can fix. It is critical to share the importance of addressing the technical debt and best practices for reducing it or at least preventing it from creating a new one. "Educate and share with your team" is my number one when discussing technical debt.
My story with technical debt
As for me, technical debt keeps chasing me everywhere I go, and that is completely fine. It is enjoyable to see code metrics improve when fixing it. Whenever I feel like having a challenge or fixing something in a more relaxed atmosphere, I have plenty of technical debt to choose from :D