When we talk about “technical debt” it seems to convey the idea that you are creating an obligation to fix things later that will behave nicely and predictably, like an open balance on your credit card. You know what you over-spent, it will grow over time due to a pre-specified interest rate, and possibly late fees. It may, in extreme circumstances, get an increase in interest, but the good government generally limits how badly they can hit you. At the heart of things, though, the original amount stays at what it was and doesn’t create interaction effects with other credit card debts. The more I consider technical debt, particularly across the activities of the development team, the more I confess to some concern about this assumption of constrained, predictable behavior. Do we actually have more of a Hydra with many heads that sprout more as we cut them off, spewing poison to our other efforts in the process?
First off, the team as a whole may incur debt that is more than “technical”, even when they are scrupulous about intentionally deferring development efforts. I ran across Mary Gorman and Ellen Gottesdiener’s article about Analysis Debt this week that got me thinking not only about the different types of debt we can get in to trouble with, but also about the potential for interaction effects among them. Another article by Johanna Rothman added fuel to that fire as she considered the causes of technical debt and their impact on your choices for climbing out of debt.
We accept that a mistake in the requirements phase will be far more expensive to fix if we discover it late in the game. It seems to me that debt that is incurred by putting off requirements analysis would reasonably have a similar impact. When we are uncertain about scope, content, goals or other aspects of requirements, we either have to build in potentially excessive flexibility to handle the range of outcomes gracefully later or risk some unknown refactoring cost. Let’s face it, if the requirements issue we are wrestling with was simple or easy to resolve, we wouldn’t be considering putting off that analysis, now, would we? (Yes, this is an exaggeration, but we generally do avoid the messy stuff for just that reason.)
Once we have even a few messy analysis decisions deferred, and team staffing commitments put off due to other brush fires, such as testers having to do regression testing on the current release of some other product, we now are struggling to feel comfortable with whether we are done with what we have and we aren’t terribly sure what success will look like for the next bits that are in the queue. The interest compounds not just due to elapsed time for the analysis that we put off, it is now generating more debt in other areas of the team.
What do you think?
