NDepend has functionality for “Smart Technical Debt Estimation”, which definitely piqued my interest. So what is it? They summarize it the following way on the NDepend startpage:
NDepend is the only Visual Studio extension that is able to tell the developer that over the past hour, the code just written has introduced debt that would cost for example about 30 minutes should it have to be repaid later. Knowing this, the developer can fix the code before even committing it to the source control.
That sounds both impressive, and terrifying at the same time. I think most developers can probably come up with some form of definition of as to what technical debt is (or isn’t), but I looked up the documentation for NDepend’s technical debt estimation feature, to see how they define it. The documentation linked to an article by Martin Fowler, and it also included this wonderful quote that really summarizes technical debt elegantly:
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
That quote really hits home. A lot of those “temporary” hacks might end up sticking around for a lot longer than intended, and as the code base grows it’s also easy to forget about those quick and dirty little fixes that are scattered around the code base—until they blow up in your face.
Up until now, I’ve primarily used NDepend to get an overview of the coupling between various pieces of code, and I’ve used its feature for calculating cyclomatic complexity to spot unwieldy methods that ought to be broken apart into several smaller pieces. When I started using NDepend, I was working with a reasonably large legacy code base, that had thousands of rows of code that I hadn’t written, but that I had to deal with. So with NDepend I managed to get a better understanding of how things were actually wired together across the code base. I found a couple of pretty complex methods, and one of the methods that caused me a lot of headache had a cyclomatic complexity of 38 (which is quite a lot). All of that is obviously very helpful, but it would be even better if we could prevent that stuff from getting committed in the first place. So if you reread the first quote about NDepend’s feature about technical debt estimation, then that pretty much seems like what it’s meant to offer.
So how does NDepend actually come up with those technical debt calculations? In the documentation that I linked to earlier, they write:
Each rule in the set of default rules contains formulas to compute the technical-debt and the annual-interest for each issue. Rules and formulas can be created and customized to better match your teams’ needs and habits since it is only raw C# which can be edited in Visual Studio.
The page with the default rules (the link in the quote) shows some examples of how the debt is calculated. As an example, under “Code smells > Avoid types too big” they have the following line:
Debt = (staticFactor*locJustMyCode.Linear(200, 1, 2000, 10)).ToHours().ToDebt()
And in that case, it factors in the whether it’s static without mutable state, as well as the number of lines of code (LOC), in order to come up with an estimation.
Quite interesting and potentially very profitable if used correctly. I’m going to run it at the code that I’m currently working on, and see what comes out of it. If you’re interested in learning more about that feature, or how the calculations are performed, then do check out the links that I posted above for more in-depth information.