#Management 11/08/2019
What is technical debt ?
As this name suggest it, it’s really similar to a financial debt. Typically, your team is short on a deadline, and you cut the corners, just a bit, to get on time. But it’s ok, it will be fixed later. Congratulation, you contracted a debt.
But next deadline is already on the way. You have to build on the top of this previous state, but don’t have time to clean up and keep postponing. … and keep postponing.
You end up with a mess that is only calling for more mess. Your team velocity is getting lower and lower. To the point that one day, you have to redo it all to move forward. And this has a really high cost : You have to pay the debts and the interests you accumulated.
Wait, is it avoidable ?
Tell your team “No debt! Never ever contract one !”, right ? Well it ain’t that simple.
We are all human, and so we don’t create master pieces every day. More than often, our creations are average and need time to get refined. But this extra time isn’t always available right away. Sure less experienced staff will generate more debt than senior, but don’t put responsibility for this on your team.
Now, for a moment, let’s pretend you have a killer team with 100 years experience in last week new technology. Your project scope will change. As it grows, unexpected features will appear and change. Solution developed at one step may become irrelevant for the next. Sadly you can’t predict the future, and so end up with debt anyway.
- Early feedbacks ask you pivot heavily.
- After one year of development, your frontend framework is 2 version late.
- Due to market feedback, you need a total rebrand, so a total design change.
- …
You can’t keep your project in a “perfect” state, it’s a living and changing object. So you can’t prevent debt to be contracted…
So how to handle it ?
Debt is to be assessed and tracked. This way you know how much length of the rope you have and don’t end up choking on it.
Scope and feature development should be discussed with all project’s actors. The same apply to the debt. Couple of simple routines can be organized :
- Spend some of time every week to rework the debt on your critical path
- Apply the rule of “Leave it cleaner than how you found it”
- Plan and organize your code to isolate “bad code”
- Prototype more (When the prototype end in the trash, so it’s debt)
- …
Talk with your team to find your solutions.
A balance to find
Let’s examine the two extreme.
Don’t become a code base maniac. It will not do you any good. As we talk above, things changes all the time. Spending time to refine items that are not critical, easy to fix, that you don’t plan to expand, … will not push your project forward, but cost you time / money non the less. Creators gonna tend to push toward this side.
And then, there is the other dark side. You know, business owners sounding like “Let’s move faster / make it cheaper, but don’t talk about your own problems”. They walk blind until the edge, to realize that :
- The tech team is mostly gone.
- New candidates never stay long if they stay at all.
- And they cannot afford at total retake.
Technical debt, like most of tricky problems, is a human one. Business want to move faster while Techs want more stability. The combination of both is well known as agility. And it can’t happen unless people talk and share honestly around a table.