Ever rush a feature, only to find it’s hard to expand later on?
Ever get a quick patch out the door to fix a crash, then months later have to resolve the deeper issue?
This is what happens when shortcuts are taken in a codebase that have to be paid later. We call it technical debt.
What is technical debt?
In short, the technical debt definition is a “debt” of work that needs to be done later on. Often the trade off is worth it: get some basic features shipped to start generating cash flow, invest time making it better later on. Other times you can accrue technical debt through poor code architecture or feature miscommunication.
There are two ways to look at code debt—managing it and limiting it.
Technical debt is common and builds in just about every codebase from time to time. With a little planning, you can prevent it from causing issues.
Reduction
A good way to limit technical debt is to clearly communicate your current and future needs for each feature. The key here is future needs. Projects will start off with some assumptions about how things will be used. If you know you want to change or add things later, let your developers know. They can build things in a way that is easier to expand later. This is also a good way to save money as things get harder to change as the code base grows.
Management
Managing technical debt is just as important. Sometimes getting things done fast is more important than writing perfect code. If you find you’re in a position where you need to ship as soon as possible, be sure to document what will need done to improve it and add it to your backlog. Make sure the improvements are clearly explained. The last thing you want is to forget about the weak point and build around it. If you know you’re creating technical debt, make a plan to pay it.
Technical debt is common and isn’t a death sentence for your code base. Limiting it wherever possible and managing it when you need to can help keep your code clean and your project going smoothly.
