You may not have heard the term “technical debt” before if you aren’t a developer. But, if you’ve worked with custom software at all, you’ve almost certainly felt the effects. So, what is technical debt, and what can you do about it?
Techopedia has a pretty solid definition:
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. Technical debt is commonly associated with extreme programming, especially in the context of refactoring. That is, it implies that restructuring existing code (refactoring) is required as part of the development process. Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem. Technical debt may also be known as design debt.
Or, if you just skipped that whole section as TL;DR, I’ll sum it up. Technical debt happens when a programmer decides (strategically or not) to go with a solution that gets the job done, if not always in the most effective way for the long term.
Technical debt isn’t always a coding problem, though. Sometimes business choices like rushed planning, the wrong tech stack, or other stakeholder decisions can increase a project’s technical debt. That’s why Centresource likes to get in on a project as early as possible. Allowing our strategists access to those early decisions will ultimately make development a lot faster and easier.
Technical debt happens. Accruing it does not (always) mean you have a bad programmer. Some cases call for the quick and dirty solution, understanding that it will have to be adjusted at a later stage.
The key to technical debt? Strategy.
Wait, Technical Debt Can Be a Good Thing?
The short answer is “sometimes.”
What many people forget is that computer programming is, at its heart, a creative task. Developers are often such logical people that we forget that they are creating, often from nothing, complex solutions.
That kind of creativity leaves detritus.
Think about the last time you created or learned something new. If you’re an artist, you know a lot of bad drawings happen before the best one comes out. “Mess” is a part of any creativity–including programming.
When developers are working on a new feature, there will be a lot of ways to solve the problem. The key is to find the best one, but they can only get there by trying multiple different options. Like a chef in the kitchen, the mess you’re making for the current meal is good, because it gets the food to the table. The problem happens when the mess stays around.
Aside from the creative need for a little technical debt, sometimes you’ll find there are legitimate reasons to choose a “good for now” solution to a problem. Budget, timeline, and other product features may all lead you to decide to knowingly take the duct tape solution, while planning to fix it in the future.
The key is strategy. It’s purposely choosing that option, with a basic plan to iterate on it in another phase of the project.
Crisp’s Blog has good illustrations of how to think about good and bad technical debt, if you’re interested in diving a little further on it.
I Have Technical Debt–Now What?
Don’t panic. Just like with consumer debt, there are strategies to deal with technical debt. Every project is different, but technical debt is not an unclimbable mountain.
In the next week, we’ll talk more about how we handle technical debt at Centresource.