In my last post, I introduced the ‘technical debt’ metaphor and talked a bit about why it makes a lot of sense.  In this post, I’d like to dive into why technical debt is so important and what you should be doing about it.

Why is technical debt important?

Technical debt is often overlooked because it generally has symptoms that lay ‘beneath the surface’ to the average user or manager.  By the time the symptoms become visible to the real world, it’s generally too late.  Those who ignore the importance of technical debt do so at their own peril.  Here’s why it should be top of mind:

• You are likely to face challenges with technical debt at some point in the future.  That is, of course, unless you are already have accumulated some and don’t know it yet.
• It is a problem that you sort of want to have.  That’s because it is a problem that scales with success and growth of your organization.  The faster the outside world makes you go, the more likely you are to rack up debt.
• If you don’t deal with it, it will catch up to you.  And when it does, it’s likely to be a big problem, such as downtime, slow velocity, or low engineering morale.

However, if you are smart enough to actually take the concept into account and work diligently to ensure you don’t go bankrupt, you’ll be a much better company.   You’ll be more agile and lean in the future because you’ll have a codebase that is ready for change and quick iteration.  If your code and/or infrastructure become stale and brittle, then you are simply asking to eventually become irrelevant.

In my opinion, velocity is the key competitive advantage in any business: young or new.  If you don’t have the foundation laid to go fast when you need to, your competitors will be able to out-innovate you.

What should you be doing about technical debt?

Step 1: Acknowledge it

Now that we know how important technical debt is, we can look into figuring out how to stay ahead of it.  The first thing to do is acknowledge that it exists.  While this sounds sort of simple, it actually can be more challenging than you think.  Most organizations have cultural elements that impede progress in recognizing debt.  In many organizations, sweeping things under the rug is a great way to keep management off of your back.  If you admit that something out there is sub-optimal, you’ll often get hounded and reprimanded by superiors.  In many organizations, the working environment doesn’t exactly value honesty and openness.  Mistakes are embarrassing, so you are better off not bringing them up.

You cannot let this be your organization!!  Work to create a culture of honesty and open communication.  People shouldn’t be embarrassed of finding sub-optimal technical issues.  Instead, they should feel a sense of ownership and empowerment.  The best way to get issues like this on the table is to explicitly set aside time for digging into them.  I’ve had a lot of success with carving out time to talk about technical debt at the sprint/release planner level as well as bringing it up in team retrospectives.  If you don’t explicitly ask for people to think critically about areas for improvement, they may never bring them to light because they are so focused on driving velocity with the upcoming features.

Step 2: Pay it back

Now that your organization knows that technical debt exists, you need to start allocating time to pay it back.  The best way to allocate time to paying down technical debt is to build it into the velocity calculations of your existing iteration planners.  That approach works whether you are using story points for estimation or hours for estimation.  Let’s say that your team has an average velocity of 10 story points for each iteration.  But you’ve come to find that there are is some sub-optimal code sprinkled throughout the  codebase.  You can start by allocating 20% of your time to paying down the debt.  So the team can take 8 points of normal feature work and 2 points of technical debt work off the backlog.

The key here lies in staying consistent.  Whatever you do, try to keep it up and make it part of your normal team process.  If you decide to maintain a backlog for technical debt, or you want to build technical debt tasks into your main backlog, just be sure to continue revisiting it and re-prioritizing it (like you should be doing with all your other tasks).  And be sure to consistently spend some velocity, even if its a very tiny amount, paying down the debt.  Just like with any amount of debt, you don’t want to continually be running a deficit.

Occasionally, you may find yourself in a place where you can do a ‘big payback’ of debt.  That’s sort of like overpaying on your mortgage to pay down the principal — it can’t hurt.  Sometimes the urgency of feature velocity is lower than others.  Also, sometimes there are bottlenecks in other parts of the organization that give you some time to focus.  At ModCloth, we engage in a ‘feature-lock’ around Holiday time, which gives us the ability to spend a little more time on debt than usual.

Some takeaways and other insights

So we’re done exploring some of why technical debt is so important and what you can be doing to stay ahead of it.  Some things to keep in mind going forward are:

• This is one of the more advanced concepts of engineering and product development.  Don’t beat yourself up if you aren’t effectively managing it yet.  If you’re thinking about it, you are ahead of most of the game.
• Effectively managing your technical debt really falls under the bigger umbrella of staying relevant and agile.  Agility allows you to be ready for change.  Anyone that has been in product development for long enough knows that your product is likely to become more of a liability than an asset at some point in the future.  The degree to which you can keep your technology relevant is the critical factor in how long your product remains an asset.