What is technical debt?

Think about every time you've asked a developer to do something quickly. He or she probably protested a little bit and explained that there isn't enough time and that you need to cut the scope of work to meet the deadline. It was critical for the business to meet the deadline so you pushed back and your team delivered! Congratulations on shipping, but you've just sacrificed the long-term for the short-term and taken on technical debt.

When your developer said there wasn't time to complete the project what he or she meant was that there wasn't time to do the project properly. Software that is developed for long-term stability and speed usually has several things:

1. Excellent documentation, both technical and business-related
2. Well-architected, organized, and extensible code
3. Functional tests
4. Automated (unit, integration) tests

Since the customer does not see these things directly, they are the first things to be sacrificed when time and scope are both fixed. This sacrifice is the act of taking on technical debt, and servicing debt costs you interest.

What are the symptoms?

"My software works and I hit the deadline, so who cares?" you might ask. Technical debt, just like financial debt, isn't inherently bad. Using a credit card to buy food is better than starving. Meeting a deadline for a big customer is better than losing them and putting the business at risk.

Technical debt only becomes a problem when you don't make payments on it. Old debt accrues interest and new debts get added on. The whole thing snowballs and you'll start seeing the following symptoms:

1. Your product breaks a lot, often without anyone making changes to it
2. Even seemingly small changes take forever to ship
3. When you eventually do ship new code it breaks something unrelated
4. New developers take forever to learn everything and be productive
5. Developers nearing the 2 year mark start quitting

Sound familiar? You can make these problems better, but it requires you to do something that isn't fun: paying down technical debt.

How do you fix it?

From a business standpoint, paying down technical debt is painful. Other than increased stability, the work your team does will not be visible to the customer.

1. Stop taking on new debt

The critical first step to paying down technical debt is to stop taking on new debt. If you must continue adding new features to the product, allow your developers time to do their work properly. Refuse to ship code that lacks documentation, tests, or is poorly organized.

2. Document, document, document

Once you've stopped the bleeding, work on creating documentation first. Start with the business stuff first: why was a particular feature created? What problem does it solve? Then tie that to the technical documentation, both in prose and code. Documentation moves knowledge from developer brains (which can quit) to the company (which can't) and can be passed to new employees without additional effort.

3. Write tests

Start with functional tests. You're already doing this before you ship a feature by making sure everything works. Simply write down detailed basic testing procedures then expand them from there. The beauty of this is that you can then hand the script to a lower-paid employee and they'll be able to test for you.

Once you've developed functional tests ask your developers how much of them they can automate. This is even better: you'll know within a few minutes of changing code whether something is broken. In parallel, your developers should also start writing integration and unit tests.

4. Refactor

Once you have extensive test coverage the real fun starts: going back and fixing all the hacky, poorly-organized code you have lurking in dark corners of your software. With tests in place your developers will be able to re-architect and re-organize with a reasonable level of confidence.

Outcomes

What can you expect after paying off technical debt? You should see the above pain points start to melt away. New developers will onboard faster, your team will ship new features faster, and your customers will stop complaining that your software is full of bugs.