Architect Tip: What is Technical Debt?

Welcome to Architect Tips presented by Clear Measure, a software architecture company. Empowering .NET development teams to be self-sufficient, able to move fast, deliver quality, and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to [email protected] and the next tip could be yours!

What is Technical Debt?

Now we all want to move fast and deliver consistent quality and run our software in production with confidence knowing that everything works and we won't be surprised by bugs getting through. And at this point, if you haven't been paying attention to the podcast, we sponsor the Azure DevOps podcast, then check that out and specifically, listen to Episode 150 with Capers Jones. I highly encourage you to do so. Capers is probably the most prolific publisher of research in the software industry, and his research shows quality precedes productivity. And if you want your team to go fast and you focus on that, then your quality is likely to suffer. You won't go fast at all. It's an interesting dynamic, in an attempt to move fast. You may skip some automated test cases or push something out without fully thinking through all the aspects of the design and then when a production bug happens, a developer stops working on a feature and spends time fixing the bug. And in this instance, we discovered new work. We've known about new work that had to instantly move to the top of the priority list pushing back, other prioritized feature work and it's very likely that the developer loses half a day or more fixing the bug. And then there's more pressure after that to finish the feature. And if that feature doesn't have a complete design or complete level of automated testing coverage, then a bug in it will surface at some point soon. Repeating the cycle and on aggregate, the discovery of bugs and the efforts to fix them can end up consuming a lot of development time. And from the outside of the team, it can appear that development doesn't move very fast. But in reality, the development of new features people are waiting on move pretty quickly. They can be pretty simple features. But because of the quality issues, the remaining development capacity left in the week to actually work on new features is not a full-time effort. It could be a fraction of the development week. The point at which all development time in a week is used to fix existing defects or we're not working on developing new features at all. We're just fixing things that broke that is complete development bankruptcy, where were sunk.

 Now, some people call this Dynamic Technical debt, and it's called this to invoke the metaphor of interest payments on a credit card. If my paycheck is $4,000 per month and I pay $100 per month to pay the interest that has accrued on a credit card on the amount that I've charged, then I can keep going and manage that because I have $3,900 per month left of available cash and pay other expenses, whatnot.

But if I continue spending above my means and charging it to a credit card, then there will come a time when I'm paying all of my money that I have every month just to pay the interest on the rather large balance. And at this points its all over a cliff, my margin for adjusting my r recovery is gone. I can't pay it down. I just don't have the means. So technical debt in software is in complete design and sufficient automated test coverage. You could think that hey, I paid for a feature or your business partners or customers paid for a feature and development. We pay for a feature by working on it, spending time on it. If I pay for a feature, but if I only pay for some of it, then the rest is technical debt. And so the rest of it I put on the charge account to be paid in the future and in the future when a bug surfaces because of an incomplete design or insufficient test coverage. I’lll have to pay down that debt and likely when I have no automated test covering all the paths. I'm going to slip through and I'm going to have to pay down that debt at that point of payment. Of course, in this scenario, all in the form of time. And anyone who's been doing development for some time has experienced situations, where they have their week, all planned out nicely.

Feature A we will chip on Tuesday, feature B well chip on Friday. And then in comes a bug surprise. Now, your schedule is hosed. You can try to explain why Feature A or B, didn't make it in time. But what will you say? Some gremlin got into the code and broke something. It's not my fault when it comes down to it. The only truthful thing to say is that either a previous design was incomplete or I didn't cover all the behavior paths with tests to prove them. Either way I told you, a feature was complete last week or a few weeks back and now we can see that the feature wasn't complete. And now I have to work more to finish the work that I had previously reported as finished. So that is what people talk about. When talking about technical debt, it's work that we should have done, but we put it on the charge account and it's going to come back to us at some point. So I hope this helps. Stay tuned for more tech tips and keep shipping.

Thanks for watching Architect Tips. If you would like help improving your team speed, quality, or software stability, send us a note to [email protected]. On