« Stop Sacrificing Readability For Efficiency! | Announcing DCPHP.net » |
Much has been written about technical debt, and the way it’s both accrued and paid off. For the uninitiated, here’s the definition of technical debt:
The amount of time, money, or effort it takes to work around, manage, and fix bad decision/implementation decisions. (CaseySoftware)
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.
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
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
« Stop Sacrificing Readability For Efficiency! | Announcing DCPHP.net » |