Editorial note: I originally wrote this for the NDepend blog. You can check out the original here, at their site. While you’re there, check out the tech debt features in the newest version of NDepend.
Recently, I posted about how the new version of NDepend lets you compute tech debt. In that post, I learned that I had earned a “B” out of the box. With 40 minutes of time investment, I could make that an “A.” Not too shabby!
In that same post, I also talked about the various settings in and around “debt settings.” With debt settings, you can change units of debt (time, money), thresholds, and assumptions of working capacity. For folks at the intersection of tech and business, this provides an invaluable way to communicate with the business.
But I really just scratched the surface with that mention. You’re probably wondering what this looks like in more detail. How does this interact with the NDepend features you already know and love? Well, today, I’d like to take a look at just that.
To start, let’s look at the queries and rules explorer in some detail.
Introducing Quality Gates
Take a look at this screenshot, and you’ll notice some renamed entries, some new entries, and some familiar ones.
In the past, “Code Smells” and “Code Regressions” had the names “Code Quality” and “Code Quality Regression,” respectively. With that resolved, the true newcomers sit on top: Quality Gates and Hot Spots. Let’s talk about quality gates.
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look at the technical debt functionality in the latest version of NDepend.
The idea of technical debt has become ubiquitous in our industry. It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code. Then, from there, it grew to define perhaps the foundational of tradeoffs in the tech world.
You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt. It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning. “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”
As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more. Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it. And so shops constantly grapple with the question, “how can we reduce our tech debt?”
I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt. First, I’d tell you to reduce problematic coupling. Then, I’d tell you to stop it with the global variables. You get the idea.
But today, I want to do something a bit different. I want to talk about the one thing that every company can do to reduce tech debt. I consider it to be sort of a step zero.
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site.
The term “technical debt” has become ubiquitous in the programming world. In the most general sense, it reflects the idea that you’re doing something easy in the moment, but that you’re going to pay for, with interest, in the long run. Conceived this way, to avoid technical debt would mean to avoid taking out these “time loans” in general.
There’s a subtle bit of friction, however, when using the (admittedly very helpful) concept of technical debt to communicate with business stakeholders. For them, carrying debt is generally a standard operating procedure and often a tool, and it doesn’t have quite the same connotation. When developers talk about incurring technical debt, it’s overwhelmingly in the context of “we’re doing something ugly and dirty to get this thing shipped, and man are we going to pay for it later.” That’s a far cry from, “I’m going to finance a fleet of trucks so that we can expand our delivery operation regionally,” that an accountant or executive might understand. Taking on technical debt is colloquially more akin to borrowing money from a guy that breaks thumbs.
The reason there’s this slight dissonance between the usages is that technical debt in codebases is a lot more likely to be incurred unwittingly (or improvidently). The reason, in turn, for this could make up the subject of an entire post, but suffice it to say that the developers are often shielded from business decisions and consequences. It is thus harder for them to be party to all factors of such a tradeoff — a role often played by people with titles like “business analyst” or “project manager.”
In light of this, let’s talk about avoiding the “we break thumbs” variety of tech debt, and how NDepend can help. This sort of tech debt takes the form of “things you realize probably aren’t great, but you might not realize how long-term damaging they are.”