The metaphor of technical debt can be quite useful. In fact Don Jones makes a compelling case for just how good a metaphor it can be. However, like most metaphors it can break down and lose its usefulness. You usually incur debt when you purchase something and you don’t have the money (or desire) to pay for it up front. You know what you’re buying, you know what it costs and you know how much debt you’re taking on. Sometimes you even know if you can afford it. 

Software technical debt, on the other hand, can feel like the end result of planning to buy a split-entry three-bedroom in the exurbs but ending up with Downton Abbey. Sure, you own a castle, but it’s hundreds of years old with bad plumbing, inadequate electrical wiring and requires an entire staff just to keep it clean and minimally functional. You keep thinking, “How did I get here?"

While on the surface this might seem ridiculous, it doesn’t happen once in your lifetime. It has an annoying tendency to happen once in the lifetime of every software project. Workarounds, dependencies and broken processes are considered a part of dev life, but how do you know when it’s too much for your team? What are the warning signs of too much tech debt?

The most important aspect of technical debt is recognizing when you and your team are purchasing it. But how do you do that? There are several warning signs. But first, a story you may know all too well. As a development manager, typically you’re part of this conversation:

Customer: “We’re really interested in seeing Whizbang. Can you get that working in three weeks?"

Developer: Well, as you know Whizbang wasn’t even planned for this version. It will delay our initial delivery, but let me see if I can cram it in there."

Customer: “Great, I knew I could count on you. Thanks."

Customer heard that the schedule is going to slip (you craftily didn’t say by how much). What wasn’t understood was that “let me see if I can cram it in there” has a very real ongoing maintenance cost that we call technical debt. While we often acknowledge the scope creep, and if we’re lucky the schedule hit, it’s much harder to recognize the technical debt that accrued to accommodate those changes.

Here’s what happens next: as the software development manager, you may find yourself behind the wheel of a large (soon to be out of control, brakeless) automobile that’s off the project road map, fast. You stop your well-planned and predictable software development process. You have your team work like crazy to get Whizbang working in three weeks. Along the way you have to make some compromises, sure. Your team probably makes a few classes globally accessible. They move other methods into classes where they don’t belong. 

Your team even has to swerve once or twice to avoid some best practices. You are doing what it takes to add the functionality in the fastest possible way without regard to how it will affect long term maintenance. It’s important to recognize that while taken in isolation, each violation appears to be only a venial sin, but in the aggregate it’s a much more serious issue. But hey, you’ve gotten the car to destination, yet now it’s time to pump the brakes and get back on track, right? Your plan is to spend the next three to six weeks fixing this and paying down the technical debt. However right now, it feels like a win--you and your team just made the impossible happen and made it happen on time.

The customer arrives and is impressed. Before the back-patting is done, the customer also mentions that if your product also had GollyGee, his business would be yours. It also just so happens, he’ll be back in a month and would love the chance to get a preview of the GollyGee feature. More scope creep and not enough time to incorporate those changes correctly. You know more technical debt is on the way and all you can think think is: "My God, what have I done?"

Nonetheless, you’re back behind the wheel of a larger, faster, even more juiced up automobile and you have your team do whatever it takes to get GollyGee done for the customer visit...and the technical debt starts piling up. This may sound fabricated and unrealistic, but I promise you, aside from the silly names, it’s happened to me and it’s probably happened to you and your team. If it hasn’t, it will.

The problem is that from the outside there doesn’t appear to be anything wrong with the project. The new features actually work. Sure, your team lost a week tracking down a bug when you added GollyGee because they had a conflict in the new global class that was so helpful for Whizbang. However, once they realized what the problem was, they just violated Don’t Repeat Yourself a teeny bit and hard coded an alternate solution. That lost week of course was a micro-payment on the interest on the debt. Meanwhile, everyone else on the project started using that oh-so-convenient global class too--oops the technical debt is dog-piling on. The project is now significantly harder to maintain and until you fix all the hacks and shortcuts, it’s going to continue to get worse...and there you are, letting the days go by.

One reason we are so fond of the metaphor of technical debt is maintenance issues feel like compounded interest. Of course in most cases, you not only don’t pay down the principal, you’re not even making a dent in the interest. Watch out for these technical debt warning signs:

• Your team starts doing things for quantity (i.e. fast turnarounds) over quality.
• Developing the product becomes more and more difficult, and maintaining it is taking up an ever increasing amount of dev resources
• Your team has to come up with new ways to work around the quick fixes you put in place.
• You don’t go back and fix the workarounds you said you would.
• You deviate from the project road map often.
• Your team starts missing deadlines.
• More bugs, which are hard to discover and replicate, start appearing.
• Your devs show signs of frustration and the code base is growing increasingly inelegant.

Spend some time with Mark Heath’s Understanding and Eliminating Technical Debt course to get a fuller picture.

If you’ve heard technical debt is good for a dev team, you heard wrong. If you’re a software developer, they weren’t talking to you. If you’re the business owner, they might have been talking to you. Taking on the debt isn’t the problem. t’s not acknowledging, or even understanding that you took on the debt, that’s really going to cost you. If you don’t put a payment plan in place, then it’s definitely not what anyone would call good debt.

I’m sure we’ve all used software products that were buggy and annoying. Every new release seemed to bring more problems than features. They were likely victims of unpaid technical debt. As soon as we had an alternative, we ditched them and never looked back. When that company came out with a new product, odds are good we didn’t even consider them. As a business owner or a developer, that’s a dunning letter you just don’t want to ever get. 

Recognize that not only will there be a schedule hit for Whizbang, but also recognize your team will be incurring some technical debt that needs to be repaid in a timely manner. Ask your team for the bill. Part of the deal with getting Whizbang done in three weeks is you and your team simply don’t know what that debt will be. You don’t know what shortcuts they’ll have to take or what deviations they’ll make. If you don’t want to assume that risk, then you have to convince the customer they really don’t want Whizbang.

If you do opt for Whizbang, once it’s done, you should have a pretty good idea what it will take to pay off the debt. It’s probably going to be higher than you thought, but don’t shortchange yourself here. Have your team tally up the bill and present it to you. And know that if you ask for GollyGee to be done before Whizbang is paid for, not only will GollyGee be adding to the debt, but it will likely cause the cost of Whizbang to go up. And when GollyGee is done, your team will present a new bill.

Better to plan ahead, and not incur more debt than you can pay off in a timely manner. But every time your team finishes an ad-hoc change or implements some scope creep item, ASK THEM to estimate the unpaid technical debt after it’s done. If you don’t, you might find you have too much in common with the Talking Heads’ protagonist.  And instead of the split-level three-bedroom, you might  find yourself  living in a shotgun shack, in another part of the world mumbling, “Same as it ever was…Same as it ever was."

Learn how to make your dev team more productive and efficient with our guide.

Get the guide: Developers and lifelong learning: the challenges and opportunities impacting your team