Sorry for the click bate sounding title, but honestly tech debt can be a good thing. Tech debt is often a dirty word. Before we go to far, I realize that many people have different definitions of technical debt. Is it code that is old? Is it code that I don’t understand? I’ve met some people that seem to call any code that they didn’t write, “tech debt”. My definitions of Debt Dept is:
Tech Debt: Any piece of code or architecture that slows down the development process or causes extra time to maintain.
You might say that that doesn’t sound like a good thing. The thing that makes tech debt a good thing is the “why” and “how” behind technical debt. If a team is following the agile process, then iteration is a critical part of the process.
Iteration and MVP implies that things are not perfect the first time. Then improvements are made to existing pieces of code on future iterations.
To be clear, technical debt is not just a by-product of tight deadlines and cutting corners. Good technical debt should be calculated and consist of on-purpose decisions to get to an MVP (or sometimes a MMF) before completing the full solution. This might mean hardcoding some data that “should” come from a database or putting data in an “overloaded” column.
One of the biggest challenges with technical debt as a software engineer is that it can feel like one is compromising standards or beliefs. Don’t fall into that false trap. The goal of a good software engineer is to deliver value. It can be tough, but it is important to have the self-confidence that a compromise doesn’t define us, it actually highlights how flexible we are.
The point is to see that the feature works from end-to-end. I’ve found that often times the problem with people complaining about technical debt is lack of managerial or product vision. Without a vision of why we are doing what we are doing, it is easy to start to think that code-coverage, abstraction, or some other buzz word is the goal.
Don’t get me wrong, quality should not be compromised. Unit tests should be written and QA should be completed. The compromise should be in the architecture, but in a way the either doesn’t go to far down the wrong path. Preferably, it should also lay the groundwork for the next iteration.
Another disclaimer: there are real issues with non-agile technical debt. Those issues should be added to a backlog and tackled just like other projects. Those types of things can reduce production scale, dev speed, lack of application observability, and a myriad of other problems.