For years, I have struggled to articulate technical debt to non-technical stakeholders. This struggle says something, given that technical debt makes an excellent metaphor in and of itself.
The concept explains that you incur a price for taking quality shortcuts in the code to get done quickly. But you don’t just pay for those shortcuts with more work later — you accrue interest.Save yourself an hour today with some copy pasta, and you’ll eventually pay for that decisions with many hours down the road.
So I say to interested, non-technical parties, “think of these shortcuts today as decisions upon which you pay interest down the line.” They typically squint at me a little and say, “yeah, I get it.” But I generally don’t think they get it. At least, not fully.
Lack of Concreteness
I think the reason for this tends to come from a lack of actual units. As a counterexample, think of explaining an auto loan to someone. “I’m going to loan you $30,000 to buy a car. With sales tax and interest factored in, you’ll pay me back over a 5 year period, and you’ll pay me about $36,000 in total.” Explained this way to a consumer, they get it. “Oh, I see. It’ll cost me about $6,000 if I want you to come up with that much cash on my behalf.” They can make an informed value decision.
But that falls flat for a project manager in a codebase. “Oh man, you don’t want us to squeeze this in by Friday. We’ll have to do terrible, unspeakable things in the code! We’ll create so much tech debt.”
“Uh, okay. That sounds ominous. What’s the cost?”
“What do you mean? There’s tech debt! It’ll be worse later when we fix it than if we do it correctly the first time.”
“Right, but how much worse? How much more time?”
“Well, you can’t exactly put a number to it, but much worse!”
And so and and so forth. I imagine that anyone reading can recall similar conversations from one end or the other (or maybe even both). Technical debt provides a phenomenal metaphor in the abstract. But when it comes to specifics, it tends to fizzle a bit.
The New NDepend
NDepend recently shipped version 2017. And with that version came some of these specifics on technical debt.
The software now features extensive metrics around technical debt, offering sophisticated quantification. You can read in a lot more detail here. But I’d like to speak from a narrative perspective today, as a user, rather than an expert user or representative of the product. I’d like to offer the journey of discovering the nature of computing technical debt with NDepend.
I installed the new version and decided to see how much tech debt I had piled up in my Chess TDD exemplar codebase. Then, I attached a new NDepend project to the solution and ran the analysis/report. Finally, I took a look at the new Dashboard and saw this.
Right off the bat, I have something to talk about with a hypothetical project manager for Chess TDD. Without drilling or diving into anything at all, NDepend furnishes me with some interesting information.
Apparently, I get a “B” rating, but with an additional 40 minutes, I could have an “A.” The dashboard tile colors “B” greenish, so I figure I’m probably doing okay. I also see that I have 1 day and 4 man hours of total tech debt in the codebase, apparently.
Conversation Starter Material
I have yet to even click on the “Explore Debt” and I could already supply some of the missing concreteness I mentioned earlier. If a project manager and I were to discuss an upcoming release, I could say, “look, I could spend one extra day and eradicate this codebase of tech debt — make it pristine.”
Doesn’t that seem a better conversation facilitator than my previously vague proclamations of “tech debt exists?” Doesn’t it seem promising that we can at least start to bandy about actual figures. I don’t even know exactly how accurately these describe my situation yet, because I can customize a lot of settings. But we have a starting point.
If you do click that drop down, you get a look at the debt settings for your project. I show that screen in the image here.
You’ll need to play with the specifics for yourself. I suggest a good bit of experimentation, tuning and customizing to leverage this in a way tailored to your team, but you should understand the possibilities here. This screen allows you to quantify technical debt estimates in terms of rolled up quality scores, man-hours, and currency.
Think about that for a second. Think of the discussions this allows you to have with business folks. If someone delivers a particularly nasty bit of code, NDepend can actually give you an estimate as to the long tail cost that it introduces into the codebase, both in money and time.
But It’s Turnkey
One of the things that appeals to me most here is the turnkey nature of what you get. Sure, you can do a lot of customizing. But with a couple of clicks, I found myself staring at a score and a conversation starter right in the dashboard.
I could (and probably will, in future posts) talk in detail about how the debt score integrates with the metrics you already know. I could also talk about a rich new set of options available to you through CQLinq. And, of course, I could talk about all of the cool new figures and visualizations.
But what I’d like to close with is a reinforcement of the lead here. How does one compute tech debt using NDepend? Extremely easily. Just install the new version and fire away.
I love this tool and I love this capability. I love the fact that I’ll never again struggle to make tech debt concrete to project stakeholders.