In a previous post we warned about the perils of leaving technical debt in your codebase. Tech debt is usually talked about as an unqualified bad thing. But many companies have been built on piles of Tech Debt and survived for decades. Every code base has some form of it. That leads to the question, when is Technical Debt OK – or at least less painful? This post will show cases when it’s OK to take on Technical Debt – or just leave debt ridden code alone.
Here are the criteria I use to asses Technical Debt:
- What are the goals of this software?
- What are the consequences if this software doesn’t work?
- How risky is changing the software?
- How hard is this software to change?
Weigh the risks with the benefits. For projects that are critical to running your business, Technical Debt will hurt your bottom line. If there’s little benefit and high risk, you’re better off letting a sleeping dog lie.
When is Technical Debt OK?
Proving a business model
Is this code backing a winner? Sometimes the goal is to validate an idea. It’s OK to cut a few corners in cases like this. Our goal is to see if our idea has legs. Clean code doesn’t matter if it’s losing money anyway. Think of your new idea as an investment opportunity. Commit as little money as possible until you know it will pay off.
Exploratory
This is code created as a proof of concept. Sometimes we’re just throwing something together to make sure an idea is possible. It’s hard to write clean code in this environment and often counter productive.
Short term
Some companies have fierce competition. The goal here is to innovate and stay ahead of the game. Devs frequently warn against this approach but many companies have been built like this. Be careful, this is a slippery slope. Think of this as a payday loan. Many people rely on these loans to get a quick fix for an unexpected bill. But those quick loans can quickly take up your whole paycheck. This works in software as well. We can cut a few corners to release a new feature. Just be cautious, most owners don’t have the discipline needed to make the payments once the code is released.
Code that doesn’t change
Working code is better than clean code. An example of this was when I was asked add to add small feature to an old codebase. No one had touched this codebase for years. This code was in rough shape and my change made things even worse. My programmer brain was screaming clean this up. The reality was that I was only introducing risk into the project with little benefit. This was 5 years ago and I bet the code hasn’t been touched since.
Non-critical code
What happens if the software doesn’t work as designed. Does anyone notice? Is the workaround trivial?
In conclusion
This may be seen as a bunch of excuses to write bad code. That is not my intention. It’s meant as a dose of reality. I rarely advocate creating Technical Debt. Most of my clients rely heavily on the software I write to run their business. They need a system that will continue to adapt to a changing industry. Technical Debt only slows my clients down.
This is part of a series to help entrepreneurs and business owners make the best use of their development budget. See more entries here.
Also published on Medium.