Technical debt is an interesting term in our industry. To a certain degree I feel like its a bit overloaded now. Everyone has a slight variation of what their definition of it is. I often think the variation revolves around Fowler’s “reckless vs prudent, the second, deliberate vs inadvertent.”.
Regardless, I think the general concept that is in everyone’s definition is that technical debt, if not paid back over time, can cause a code base to be unmanagable. The length of time to deliver value increases because of the complexity.
Just a refresher per Ward Cunningham:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise
So how do we know where our technical debt in our codebases? If you know you’re code base well, you can probably take some guesses, but there’s got to be a more concrete way.
Enter NDepend. This post is about tackling technical debt using NDepend to gain insight into your codebase on where your technical debt lies, and how long it may take pay it back.
NDepend
It’s been a long time since I last used NDepend. From what I remembered, it provided good breakdown and coupling, dependencies, broken code rules, etc. What I didn’t remember at all was some of the technical debt estimations and explorations, which I found to be incredible.
I pulled down a random C#/.NET Project off GitHub and ran NDepend analysis. The NDepend dashboard within Visual Studio, gives you an instant glimpse into your debt:
From here we can drill in and look at all the assemblies and all of there types with the most debt. Meaning the types that have issues that will take the longest to fix.
Once I’ve drilled down to a list of types, I can view the exact issues and navigate to that code.
Calculating Debt
The Debt Rating and Debt Ratio are determined using the SQALE method.
The SQALE method has been developed to answer a general need for assessing the quality of source code. It is meant to answer fundamental questions such as:
- What is the quality of the source code delivered by the developers?
- Is the code changeable, maintainable, portable, reusable?
- What is the design debt stored up by the project?
There are a number of configuration options for calculating the debt, interest and ratings.
A configurable number of days to develop 1000 logical lines of code is used to determine the length of time. By default this is 18 days.
Instant Insight
I was really blown away how quickly you can install NDepend, run the analysis on your solution and instantly get a high level summary with the dashboard and the ability to instantly drill deeper. Honestly, it’s only a handful of mouse clicks. It’s pretty unbelievable.
Of course the defaults are just a starting point and I would highly suggest playing around and experimenting with some of the settings. I plan on doing this myself in the coming weeks.
This tool ultimately gives everyone on the team the same view of that state of your codebase. No longer are you assuming. Concrete numbers that everyone can view.
Are you using NDepend? I’d love to hear about how you use it and any other resources you have as I’m just beginning to use it for deeper understanding and insights into my codebases. Let me know Twitter or in the comments.
What I like with NDepend is that it combines high level analysis diagrams (such as components dependencies matrix) with low-level constraints (e.g. maximum lines of code / method, maximum cyclomatic complexity authorized) that you can integrate into your CI.