Let’s Make Better Code Metrics

A few months back, I wrote a post about changes to my site and work.  Today, I have another announcement in that same vein:  I’ve recently partnered with NDepend to help start and create content for their blog.  If you go there now, you can see the maiden post which announces the release of the newest version of NDepend (not written by me, personally, if you were wondering, though some of mine will follow).

What is NDepend?

In the broadest terms, NDepend is a static analysis tool.  More specifically and colloquially, you might think of NDepend as Jiminy Cricket, if Pinocchio were a software developer or architect.  It’s extremely helpful for visualizing the dependencies and properties of your code base (e.g. complexity, coupling, etc), which will give you a leg up on your fellow developers right out of the gate.  It’s also incredibly informative, furnishing you not only with detailed, quantitative metrics about your code, but also indicating where you’re deviating from what is broadly considered to be good programming technique.  And, of course, you can do a great deal of customization, from integrating this feedback into your build to tracking code quality over time to building and defining your own complex, custom rules.

To put it more succinctly, in a world where developers are trying to distinguish themselves in terms of knowledge and chops, NDepend will give you such a huge advantage that it’s probably unfair to everyone that doesn’t have it.  I personally learned a ton about software architecture just from installing, using, and exploring this tool over the course of 5 years or so.  If you want to learn more about NDepend and static analysis in general, check out my Pluralsight course about it that I published in conjunction with the last major version. (If you don’t have a Pluralsight subscription but want to check it out, sign up for my mailing list using the form at the right).

Is the New Version Worth Getting?

You can read the release notes in detail on the NDepend site, and you can read the blog post I linked to see everything covered.  Here, I’ll just give you the highlights of my experience with the new release.

• The Visual Studio integration is upgraded and utterly seamless.  The various rules, query, and graph windows snap in beautifully and appear in places that just make sense, creating a very smooth experience.  And for those of you who use different themes than the default white, the color experience is more consistent.
• Integration with build tools, like TFS and TeamCity is a huge capability.  You could do this before, but it involved a good bit of manual labor to customize your build to capture a return code from the NDepend executable or something.  No need now — you can get this out of the box, and you should.  Years ago, I wrote about how you should make doing bad things impossible, and you should use NDepend and your team’s build to make commits of sloppy code a thing of the past.
• The rules you create can now be shared across multiple projects.  Over the years, I’ve tended to carry around an NDepend rules file with me, capturing various custom rules that I favored.  This used to involve manually editing XML, but now that’s a thing of the past.  You can have a single rules file for all of the different solutions that your team may have.
• Changes were based on user voice, meaning the things clamored for by most users made it into this version.  I just like that as a policy in general, but it also means that you may well discover small changes that you didn’t know you needed or wanted until you had them.

So, is it worth upgrading to the newest version?  Most definitely.  I think the build integration alone would make it worthwhile, but with all of these other features and goodies, there’s plenty to be excited about.  And, further, you’re going to want to be on the latest bits with NDepend if you’re going to be on the latest bits with Visual Studio.  If you go for it soon, you’ll get a discount, too — 20% off for the next week or so.

A New Blogging Series

As I’m doing with Infragistics (and some other orgs to be announced later), I’ll cross post here a bit after the fact when I’ve made posts over there.  But, if you want to keep up and read posts from more than just me about the subject, I encourage you to add the new NDepend blog to your feed readers.

As for my contributions, I’m planing to start a series of posts about creating new, composite code metrics that cross the chasm into business value a bit more than some of the ones we currently have in the industry.  It’s beneficial for us as developers and architects to be able to assess code bases in terms of cyclomatic complexity and type cohesion, but when you cite these to a manager in defense of paying down technical debt, you get a blank stare.  Wouldn’t it be nice to see comprehension instead?

Toward this end, I propose we work toward something, say for example’s sake, like “time to understand for methods.”  Imagine if you could look at that manager and say, “the average time to understand a method in this code base is 10 minutes rather than 1 minute, which means that you’re paying 10 times what you should be in developer salary for troubleshooting and debugging.”  With that in your pocket, your business case for cleaning up the code and paying down tech debt practically makes itself.

What I envision doing is starting with a dead simple (and wrong) strawman, running trials, seeing where it’s wrong, adjusting the metric hypothesis, and repeating over and over.  So, with “time to understand,” for example, it might be that we start with the initial hypothesis of “5 seconds per line of code,” see when that breaks down, refine the hypothesis, and try again.  Along the way, we’ll be discovering how to use a lot of cool NDepend features, how to customize NDepend, and perhaps some interesting properties of what makes code readable to different people.  Even if this proves too ambitious a mountain to scale, the worst case scenario is that we learn in detail how to use a really cool, powerful tool.

I plan to do this regardless, but it’ll go a lot better if there are people to follow along and volunteer for participation.  So go grab your copy of NDepend and let’s get started.  We may just have a bit of fun and talk about readable code, or, who knows, we might just figure out how to make some valuable composite metrics!