Strategic Tech Debt

At times, we choose to intentionally create tech debt. Tech debt comes in all shapes and sizes, and while encountering it makes us cringe, it is a necessary reality. When leveraged properly, tech debt becomes a strategic tool for early learnings, rapid iteration, and freeing up the team to work on the most important problems.

There are a few reasons we may choose to accept tech debt.

Speed: This does not mean it is acceptable to rush and leave behind sloppy code. It means that properly evaluated short cuts may be taken to ship faster. For example, deciding on an implementation that may not scale properly long term, but allows shipping a feature two months sooner.
Cost: Sometimes we have to save money on tooling or infrastructure that we know to be insufficient long term. For example, we may make this decision because it saves us money now and we don’t anticipate needing the more expensive solution for a while.
Uncertainty: This can come in the form of a product still working on market fit or an experiment within an existing product. If we are building an experiment as a contender (think A/B test), then, by definition, we do not know if the code will live long. Depending on the situation, we may choose to cut some corners and save the resources until we have seen how the solution is received by customers.

Context Matters

When accepting tech debt, we need to evaluate the tradeoffs and long term ramifications. To be effective, engineers need business context to make decisions around accepting and maintaining tech debt. Engineers at most tech companies are trying to balance speed of delivery, system performance, cost, reliability, etc. This means making many decisions on a regular basis that affects these variables. Engineers with insight into, not only the roadmap, but the decisions that led to the roadmap are able to use that information to make technical decisions that can have an exponential impact over time.

Contain it

In order for tech debt to be strategic, we need to make sure our tech debt doesn’t negatively impact future code in a way that causes it to spread and become code rot. To prevent this, we need to isolate our tech debt and limit the surface area of code affected by this decision. For example, if you choose a data source that you expect to be updated or even replaced as you scale, take care to define an interface and use something like the adapter pattern to encapsulate the details of the database. Isolating your tech debt gives you the confidence it won't spread and you can come back later without too much pain.

Manage it

If we are going to consider tech debt a tool, we need a way to manage it. This means having a highly visible place to capture tech debt. It is also useful to document, not only the tech debt itself, but the reasons it was accepted and any notes that helped the team make the decision. This way, when it is revisited all the information to make the decisions around paying off the tech debt is available. Lastly, we need a plan to revisit this documentation periodically and whenever planning related to this area of the system occurs.

For the process of documenting tech debt, I prefer to lean on internal system documentation rather than a ticketing system. This approach ensures one can clearly see the existing tech debt when reviewing the broader documentation and it will be hard to miss when planning any work related to that area of the system.

Conclusion

Tech debt can be useful, but when accepting tech debt, we want to make sure we do not dig ourselves into a hole we cannot escape. We need to understand the debt we are accepting and have a plan to deal with it before it becomes a burden. Tech debt can be a feature when handled strategically, it should not limit us from moving forward, instead, it should empower us to do more now and leave the door open for improving the system later.