Andy Lester gave a session called Managing Technical Debt. We’ve all seen technical debt on a project because it’s practically unavoidable. Well run projects avoid the accumulation of an unsustainable mountain of debt.
Lester likes to think of technical debt like an accountant thinks of financial debt. And this makes a lot sense. You’re probably never going to rid a project of all technical debts. In fact, you might not want too. Sometimes, a bit of debt is the price you pay for delivering a killer feature. But you always want to keep the debt at a manageable level. So, Lester prescribes a 5 Step Plan to manage Technical Debt on a project:
1 Identify your debts. Technical debt usually includes the following:
- Clutter. Anything you plan to do later is clutter. Later is never.
- Failing tests.
- Unfixed bugs.
- Ugly code. If you don’t want to look at the code, then you’re less likely to maintain it.
- Uncommented code.
- The “Bus-factor”. The centralization of too much business-sensitive knowledge in one individual leaves a project vulnerable if they leave (or, get hit by a bus).
- Inherited debt: debt that you didn’t charge up yourself. For example, an un-patched security hole in some 3rd party software or tool.
- Missing infrastructure such as proper source control tools, automated backups, automated builds, etc .
- Relying on non-open source products (i.e. MS Exchange).
- Jerks on the team.
- Jerks in management.
- Lack of coding standards. Lester took time to point out that arguments over coding standards are ridiculous.
- Code ownership. Code belongs to everybody.
- Not realizing you have technical debt. Managers who may not be very technical may not understand issues. This usually means you need to explain the debt in terms of dollars.
2 Determine the costs of technical debt:
- Think in terms of time. Debt kills you in time.
- time costs $, so think $’s too.
- Weigh the risks. Can you afford to take on a particular debt? Lester uses the example of not backing up your source control on a regular basis. This is a debt. you may never have to pay it. But what if you do? Is it worth taking on in the first place?
- Determine the cost of paying a debt. You lose opportunity when paying down a debt so it better be worth it. What if the programmer required to pay down the debt is critical path on another project? It may be better to put a less experienced programmer onto a task-even if they take twice as long-if it means the more experienced programmer can help accomplish a more urgent task.
3 Pay the most profitable debts:
- Pick one debt at a time. This is critical! Lester uses an air traffic controller metaphor for this which is “land one plane at a time”.
- Don’t pick the easiest debt.
- Always time-box your efforts.
- Your goal should be improvement, not perfection. This will help you stay within the time-box
- In general, Just Do It.
4 Stop acquiring new debt:
- When you make a trade-off, record it. It could be on the wall, in the bug tracker, wiki, etc.
- Understand your cash flow. The currency is your time. Like accounting, you need to track and be aware of what things are costing you.
5 Watch the corners for potential debt:
- Lester uses a McDonald’s analogy, where the manager on the floor is not doing regular tasks. Rather, the manager is watching the cornersby making sure the other’ workers can do their tasks. Ideally, by watching the corners the center will take care of it’s self.
- Automate the corners by automating tests.
- Debt management is an investment.
Intelliware’s use of Extreme Programming and other Agile practices makes many of these techniques familiar to us. Nevertheless, as an individual developer, it’s very useful to think clearly about the time we allocate to debts. What are the costs of adding an extra layer of abstraction to your code even if it isn’t necessary to complete a task. Will you ever reap the benefits? Could you have completed another feature-or reduced a debt-instead?