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:
Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
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 otherwiseSo 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. 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 DebtThe 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: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.
- 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?