What is technical debt, and how do you get out of it?
Okay, we all know the story. You need to add a small feature to an older project. Should be quick and easy, right? You’ve done it a thousand times. You open your favourite code editor and start digging. Oops. You now realize that the 3-hour job you initially envisioned has now turned into at least a day of fiddling around. Why is that? How did it happen? Two words: technical debt.
Technical what?
According to Ward Cunningham, the inventor of the metaphor, technical debt is the result of writing code that is easy to implement, rather than the best overall solution.
Technical debt works very much like financial debt. Whenever you borrow money, your debt increases. The longer you take to repay that debt, the more interest you pay, and the more money you owe, until you can’t pay anymore, and go bankrupt.
In our case, every “quick and dirty” piece of code that gets implemented in a project acts like a new loan. The longer you wait to refactor them, the harder they will be to fix . It’s a snowball effect: every piece of code that relies on that “good enough for now” method will need to be adjusted and so on.
“Every minute spent on not-quite-right code counts as interest on that debt.”
— Ward Cunningham
How did we get here?
There are many factors contributing a technical debt, but the most common one is “time”. Lack of time, to be more specific. Bad communication between the client and the technical team, lack of coding standards as well as unexpected features added halfway through the project are also contributing factors.
What can we do to prevent it?
The first step in preventing the accumulation of “bad code” is to establish code standards, both on the back-end and front-end sides. Then add code reviews to your flow. They are a great way to reinforce your standards, especially when the team isn’t used to them yet. Old habits die hard.
From a project management standpoint, by effectively setting and managing client expectations, as well as learning to say no, you will decrease the chances of accumulating such debt . Too often, developers are asked to add new features halfway through a project, which leads to less time spent on features that were originally planned.
So… what now? How do I pay it off?
What’s done is done, there’s no easy way around it. Basically, you have two choices. You either refactor the whole thing, or pay it off slowly but surely, debt by debt. A complete refactor requires significant time and money, so that’s probably off the table.
- Separate issues into distinct categories such as: buggy, overly complicated, doesn’t follow your newly-set standards, etc.
- Then decide which debts can be tackled first. I, for one would choose to start with smaller independent pieces of code. Small wins are always fun and encouraging.
- Lastly, just do it. Seriously, it’s the coolest part. You get to actually write some code instead of just talking about it. But take your time. As I previously stated, time is a major contributor to technical debt, so there’s no point rushing into it.
And remember, a Lannister always pays his debt (and so should you).
