Stories about Software


How to Use NDepend on a Team with Only One License

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 how NDepend can help make you a better programmer.

I remember my first exposure to NDepend.  Back then, I worked for a company that allocated software developers a budget for personal improvement.  Predictably, most people spent theirs on books, courses, and the like.  But not me.

You see, as soon as I discovered NDepend, I saw immense potential for my own career.  A static analyzer that helped with visualizations of the codebase?  This wouldn’t just help with code reviews.  It would actually make me better at software development.  I took that argument to my manager, and he agreed.  Next thing I knew, I had an officially licensed copy of NDepend.

While NDepend did, in fact, improve my chops, I don’t intend to create an entire post about that here.  Instead, I want to respond to an interesting question I heard recently.  In essence, “how can we get the most out of NDepend with only one license for the team?”  Having used my training budget to buy NDepend, I found myself in the position of having the sole license and wanting to spread the value.

In the years between then and now, NDepend has grown more feature rich.  Meanwhile, I’ve traveled all over the place and interacted with dozens of software groups, as both employee and consultant.  But the question and the conundrum remain relevant.  So today, I’ll offer some ideas on how to generate the most value for a team from only one NDepend license.

Some Ground Rules, First

Before I get into my suggestions, however, I’d like to pre-address some things that a sharpshooter reading the post might say.  In other words, it’s not that I failed to consider these things, but that I don’t want to speak to them.

First of all, please don’t comment about strategies for using the license for multiple people in violation of the spirit or letter of the licensing model.  Just as I wouldn’t bother to blog about how stealing cable is a cheaper alternative to paying for cable, I won’t talk about this subject either.

Secondly, I consider the build machine edition of NDepend a separate discussion.  When you have only that version, you have something intended to be unique.  You can use the build machine edition by, well, installing it on the team’s build machine.

And, finally, the one person with the license could, obviously, hoard all of the benefit.  But, let’s assume that the team has a non-dysfunctional dynamic and wants to succeed as a group.

So with all that in mind, let’s move on to some creative use cases.

The Designated Report Person

This option involves limiting your use of the tool to an extent.  But it does provide relative bang for the buck to the entire team.

First, have the the entire team agree about what code metrics and visuals they’d like to track.  Then, work together on customizing the dashboard and reports to your taste so that the analysis and reporting generates what you’re looking for.  You might also decide on some things that you don’t show in the report but want to track.

Whatever you decide, you can now get in the habit of generating this regularly.  Have the one person with the license do routine analysis and post the results somewhere visible to everyone.  If you’re so inclined, you could even script this and generate notifications.  In a sense, this kind of represents a “poor man’s build machine” version (but without some critical features).  You’re chasing the same basic purpose, but with relatively limited capabilities.

Still, even with the limited capabilities, you achieve important goals.  You’ll make issues and progress visible and start important conversations.

Dedicated Code Review Machine

Next up, let’s assume that you don’t want to leave any of the tool’s features on the table.  Rather than limit use by output people can share, consider a common location for NDepend.  Put it on a dedicated code review machine, in a conference room or somewhere common.

With this style of leveraging the tool, you focus more on when than who.  Specifically, you agree to use the features commonly at code review time.  I might argue that NDepend shines brightest in this scenario, anyway.

CQLinq helps you form custom queries for reasoning about code.  NDepend’s graphs and metric heat maps make excellent discussion points.  And, together, everyone can examine trend metrics, code coverage, and patters in the codebase.  Perhaps better than anything else, NDepend spurs and facilitates interesting discussions about the codebase.  So why not use it at the time that such conversations prove most important?

Going this route, you do give up raw usage time.  People will only use it while reviewing code.  But you will get mileage out of all of the features.

Rotating Code Quality Specialist

Finally, let’s assume that you don’t want to leave any of the features or usage time on the table.  And, furthermore, that you want to really up-skill the team while you’re at it.

With NDepend, you can always activate a license on one machine while deactivating it on another.  Take advantage of this to rotate your team’s usage of it.  Give each person a certain amount of time with the tool, wherein they take outsize responsibilities for code review, keeping tabs on essential codebase stats, and anything else you choose.

Of course, you’ll need to train each person a bit to get the hang of it.  But that can simply involve knowledge transfer between the current license-holder and the prospective one.  Those conversations alone will probably add value.  And, this approach democratizes expertise while spreading knowledge around.  Everyone on the team will develop a much greater understanding of the codebase during their rotation.

Or, Make the ROI Argument

I think of everything I’ve said here as interesting discussion fodder.  And, it does represent earnest advice for when you must economize.  But, I’ll close out by offering my best advice of all.

Get the tool for everyone who wants it.  Seriously.

I don’t just say that because I write for the NDepend blog or even because I love the tool, though both are true.  I say that because the business case is trivial.  Remember in the beginning of the post, when I said that NDepend definitely made me a better programmer?  Well, how long do you think before a few hundred dollars’ investment pays for itself after you’ve improved developer skill and output quality?

By all means, try NDepend out.  And then dip your toe in the water with a single license.  But if your team falls into one of the usage patterns I’ve outlined here, you should consider your endgame to be getting a license for anyone interested.

newest oldest most voted
Notify of
Mike Loux
Mike Loux

We don’t use NDepend at my job; we, like many other shops on the planet, jumped on the ReSharper bandwagon many moons ago. But, if we did, and for any tools like these, where there is a measurable, concrete benefit to having them, we consider these to be no-brainers. I recommend that all of my guys get a license (although I don’t force them to), and anyone who asks gets one as soon as possible. That’s just one of those “no argument” items. Heck, we’re actually considering stepping down our MSDN subscription level (everybody gets one of those, too, which… Read more »


I’ve used ReSharper in the past. I can say that using it definitely improved my coding style! It did slow down VS a ton though so I had to turn it off for the most part and back on when I wanted it there. Hard to say if it helped improve my skill though…at the time, there were many other influences to that end. You might say that style is a skill – and it is! But here I’m making a distinction between style and code design (class design, proper encapsulation). I don’t recall using ReSharper to that end. Move… Read more »