Put another way, technical debt is the sum total of all the hours you’ll have to work to make up for the design shortcuts and shortcomings you put into something.
Technical debt accrues in various ways – features are forgotten at design time and left out; mistakes are made in architecture; customers demand new features that will break other features. But I’ve found that every project accrues technical debt, and paying it down is critical to keeping the project on track.
I’ve got five techniques I use to help pay down my technical debt that I will share. Hopefully they’ll help you to pay down yours.
- Keep track of your technical debts. Keeping track of the debt through a bug tracker or list is the most important thing you can do. Try and keep the entries short (e.g. build new button for feature X). This will help keep the list a list of things you can actually accomplish.
- Aggressively pay down any debt you do take out. Sometimes this is hard, especially when your project managers are always pushing for new things and rarely give time to pay down technical debt. If you do step 1 well enough, however, many technical debt items can be paid off in 15 to 30 minutes, meaning you can pad estimates to allow for technical debt fixes.
- Borrow as little as possible. Insist on time to properly plan and architect any system. Joel on Software is big on the “No Code Without Spec” rule, and this makes a lot of sense. If you have a spec you have a blueprint for how an application will work at the end. The design process gives you an opportunity to go “well what if the client wants X?” And this creates a better product, that has less technical debt.
- Do not “balance transfer” your technical debt. It’s common in this day and age to balance transfer from a higher interest loan to a lower interest loan. Certainly there is a lot to be said for taking actions to reduce the accrued interest on your financial debt but I think this is a bit silly for technical debt. When faced with a situation where technical debt must be addressed and paid off, don’t let the corner-cutting of the past simply “transfer” the balance from one area of technical debt into another.
- Don’t “declare bankruptcy”. Again, Joel on Software argues against just deciding to rewrite the code from the ground up. Any argument made for this is equivalent to declaring bankruptcy – it’s deciding that the technical debt load is too high to ever pay off and we must eliminate it altogether. The problem is that technical debt doesn’t work like that. Old clients will still be using the old codebase. You’ll still have to support it. “Declaring bankruptcy” puts you into more debt from the moment you decide to do it because, for a while, you’re supporting two systems without being able to ship new features or iterations. This is bad. Don’t declare bankruptcy; it’s always easier to pay down your debts.
What’s your favorite technical debt tip? Tell us in the comments.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 3/23/2009 at 8:30 am
Categories: Best Practices, Business Management
Tags: development, application architecture, technical debt, PHP
Bill Karwin (@billkarwin) wrote at 3/23/2009 5:04 pm:I’d argue that like real-world debt, there is a way to use technical debt judiciously. Just make sure (a) you’re getting something for it, and (b) you have a plan for managing it and getting out of debt.
I was at a company where we had to get our product working for a demo the next day. But one of the features had an intractable bug, and everyone was stressing about the deadline. I said, “hard-code the feature for now, go do the demo, and then when we return from the demo you can finish the feature without stress.” It worked — because we actually had the plan and the priority to pay off that technical debt. And we had a successful demo by incurring that debt.
Brandon Savage (@brandonsavage) wrote at 3/23/2009 5:16 pm:I think you’re 100% right. Thank you for sharing that story. It’s true – you should not intentionally incur technical debt unless you have the ability to pay it off.
The problem is that technical debt you incur unintentionally. Hopefully you have a strategy for getting out of that, too. Unlike real debt where you must sign a promissory note, unplanned technical debt can bankrupt you quickly and is largely unavoidable.
Tony Arkles (@tonyarkles) wrote at 3/24/2009 8:59 am:Web apps change the situation a bit: when you “declare bankruptcy” on a web app, you get the opportunity to switch code bases without having existing customers continuing to use your old code base for eternity.
Ryan Kohn (@RyanKohn) wrote at 3/24/2009 12:01 pm:“Try and keep the entries short”
This is good advice, but it’s more powerful when combined with the partner advice to make the entries action-oriented. “build new button for feature X” is a better record than “button on X”.
Adding additional details on the nature of the debt is like increasing the down payment on a loan. Having full detail (i.e. a fully-implemented feature) is making the payment in full. The other end of the spectrum is not paying anything down up front (i.e. not recording the debt at all), which will maximize the interest you have to pay on it.
Along the same line as Bill Karwin’s story, having a plan for implementation is a good way to increase the down payment on the debt. Minimizing the amount of the debt you take is a sound investment strategy, so record as much detail as is reasonable about the technical debt you take.
I’ve written a bit about this:
http://ryan.kohn.ca/articles/how-to-take-a-break-when-programming.php
Copyright © 2023 by Brandon Savage. All rights reserved.
