Calculating the ROI of NDepend
Editorial note: I originally wrote this post for the NDepend blog. Head over to their site and check out the original. While you’re there, take a look at the other posts and the offering to be had.
Years ago, I discovered NDepend and downloaded it for a trial. At the time, I found myself working in a .NET shop where a lot of developers worked in the same large WPF codebase. Code reviews were mandated, debates were frequent and impassioned, and global variables were everywhere, to the dismay of only some of us. There was an entrenched majority that favored (or at least didn’t mind) a highly procedural style of writing object-oriented software, and nobody seemed able to put their fingers on why most feature development there had slowed to a crawl.
I was new to the group and had to pick my battles, particularly with people that had been there a long time. Developers who favored automated testing and craftsmanship principles were in the minority there and had a history of leaving out of frustration, so I knew it’d be a challenge, and I went looking for help. Among other things, I found NDepend and, after installing a trial, I recognized the power of the tool.
I recognized that it could help me as an objective, unbiased partner in making my arguments, but I also recognized that the way I approached code and architecture would never be the same. The ability to visualize architecture in real time, the ability to treat code as queryable data, the metrics, the statistics, the well thought-out code warnings… it was a game-changer for me. I just needed to convince my manager to let me spend a few hundred dollars to convert my trial version into a paid version.
It turned out this wasn’t hard, at least for me. I had the good fortune of working for a company that appropriated a tools and learning budget for each individual developer, meaning all I had to do was declare that I wanted some of my total spend to go toward NDepend. I did it without blinking. But it might be that you aren’t as lucky. Maybe you find yourself in a similar position to mine back then, but wanting to convince your manager that this powerful tool is indispensable because you don’t have a discretionary tools budget.
ROI: The Language of Management
I think I can help you here. After all, I did leverage my experience running an IT department into a Plurlasight course about how to lobby your managers for practices and tools. And the key to making a business case for anything, NDepend included, is to talk in terms of profits and losses, rather than in terms of, “it’s awesome, and it has all these graphs, and it shows me these rules, and CQLinq is the coolest thing ever, and…” You get the idea. NDepend’s coolness factor isn’t going to convince your manager to buy it for you.
When making a business case, two of the most important terms you should know are Return on Investment (ROI) and Payback Period. Return on investment, formally, is (G – C)/C where G is the gain from the investment and C is the cost of the investment. Thus, if you buy a tool and it helps you make your money back, ROI is zero. If you profit, it is positive, and if you don’t recoup your money, it’s negative. Expressed qualitatively, ROI is simply an answer to the question of, “is this worth the cost?”
Payback period is the length of time before ROI is realized. For example, if I were selling a tool for $100 that would save you $10 per day, the payback period for you would be 10 days. After 10 days, you’re in the black, as they say.
These two concepts frame the discussion perfectly for a manager. Managers almost always deal with budgets in some capacity or another, and, even if they don’t, their boss almost certainly does, so translating your wishes into budgetary concerns is critical to winning them over. ROI is how you tell them that something is worth buying. Payback period is how you tell them when they’ll see the payoff.
The ROI of NDepend
With this in mind, how would one express the value of NDepend, a static analysis tool? Perhaps concrete reasons occur to you right off the top of your head, but then again, perhaps not. After all, it can be hard to translate general goodness like “shows us where code is getting too complex” into specific financial outcomes like “will save us $300 this month.” So in case you can’t easily think of some ways that NDepend can help your group’s bottom line, I’ll offer a few.
If your company is in the habit of paying for learning activities such as training courses, books, Pluralsight, etc, you can make the case that NDepend fits neatly into that category. If the company is willing to spend money on these things, why not spend money on something that will not only explain good development practice, but actually show you where in your code you’re missing the mark? How many books or courses actually point places in your code that should be fixed? If you make this argument, you don’t need to address ROI and Payback Period, per se, since your company already accepts that learning has ROI. You just need to demonstrate that NDepend is a great learning tool.
But if that’s not enough or if you don’t have a learning budget, there are other arguments that area easy to make. Take the subject of code review. If you don’t have code review, present NDepend as an automated code review tool and talk about the ROI on defect reduction, since code review is arguably the most effective way to reduce defect counts. Figure out the cost of defects in terms of hours spent debugging (and, if you’re feeling adventurous, include an estimation of the actual, external cost of defects as far as brand/reputation goes), and then speak to your manager about payback period if you could eliminate just a few per month. “Look — if NDepend helps us eliminate 4 defects a month, it will pay for itself in 2 months.”
If you do have code review, go a different route. Observe some of these reviews and see what the most common items that come up during review are. Are they things like “too many parameters to that method” or “man, that class looks way too complex?” Tabulate these review action items and see how many of them could be detected with CQLinq. Once you have a sense of that, you can start to put an estimate on how many hours are spent observing and correcting things in code reviews that NDepend could point out automatically. From there, NDepend’s payback period is a pretty straightforward calculation of average salary times the hours spent on review items that could be automated.
These are just a few examples, but I’m sure you could think of more if you were so inclined. It’s just a question of getting your brain to start operating this way. There is no shortage of ways that NDepend can pay for itself, so it’s an excellent first candidate for you to hone your business case skills.