NDepend

Improve your .NET code quality with NDepend

Static Analysis and The Other Kind of False Positives

A common complaint and source of resistance to the adoption of static analysis is the idea of false positives.  And I can understand this.  It requires only one case of running a tool on your codebase and seeing 27,834 warnings to color your view on such things forever.

There are any number of ways to react to such a state of affairs, though there are two that I commonly see.  These are as follows.

  • Sheepish, rueful acknowledgment: “yeah, we’re pretty hopeless…”
  • Defensive, indignant resistance: “look, we’re not perfect, but any tool that says our code is this bad is nitpicking to an insane degree.”

In either case, the idea of false positives carries the day.  With the first reaction, the team assumes that the tool’s results are, by and large, too advanced to be of interest.  In the second case, the team assumes that the results are too fussy.  In both of these, and in the case of other varying reactions as well, the tool is providing more information than the team wants or can use at the moment.  “False positive” becomes less a matter of “the tool detected what it calls a violation but the tool is wrong” and more a matter of “the tool accurately detected a violation, but I don’t care right now.”  (Of course, the former can happen as well, but the latter seems more frequently to serve as a barrier to adoption and what I’m interested in discussing today).

Is this a reason to skip the tool altogether?  Of course not.  And, when put that way, I doubt many people would argue that it is.  But that doesn’t stop people from hesitating or procrastinating when it comes to adoption.  After all, no one is thinking, “I want to add 27,834 things to the team’s to-do list.”  Nor should they — that’s clearly not a good outcome.

With that in mind, let’s take a look at some common sources of false positives and the ways to address them.  How can you ratchet up the signal to noise ratio of a static analysis tool so that is valuable, rather than daunting?

Continue reading Static Analysis and The Other Kind of False Positives

The Biggest Mistake Static Analysis Could Have Prevented

As I’ve probably mentioned before, many of my clients pay me to come do assessments of their codebases, application portfolios and software practice.  And, as you can no doubt imagine, some of my sturdiest, trustiest tools in the tool chest for this work are various forms of static analysis.

Sometimes I go to client sites by plane, train or automobile (okay, never by train).  Sometimes I just remote in.  Sometimes I do fancy write-ups.  Sometimes, I present my findings with spiffy slide decks.  And sometimes, I simply deliver a verbal report without fanfare.  The particulars vary, but what never varies is why I’m there.

Here’s a hint: I’m never there because the client wants to pay my rate to brag about how everything is great with their software.

Where Does It All Go Wrong?

Given what I’m describing here, one might conclude that I’m some sort of code snob and that I am, at the very least, heavily judging everyone’s code.  And, while I’ll admit that every now and then I think, “the daily WTF would love this,” mostly I’m not judging at all – just cataloging.  After all, I wasn’t sitting with you during the pre-release death march, nor was I the one thinking, “someone is literally screaming at me, so global variable it is.”

I earnestly tell developers at client sites that I don’t know that I’d have done a lot better walking a mile in their shoes.  What I do know is that I’d have, in my head, a clearer map from “global variable today” to “massive pain tomorrow” and be better able to articulate it to management.  But, on the whole, I’m like a home inspector checking out a home that was rented and subsequently trashed by a rock band; I’m writing up an assessment of the damage and not judging their lifestyle.

But for my clients, I’m asked to do more than inspect and catalog – I also have to do root cause analysis and offer suggestions.  So, “maybe pass a house rule limiting renters to a single bottle of whiskey per night,” to return to the house inspector metaphor.  And cataloging all of these has led me to be a veritable human encyclopedia of preventable software development mistakes.

I was contemplating some of these mistakes recently and asking myself, “which was the biggest one” and “which would have been the most preventable with even simple analysis in place?”  It was interesting to realize, after a while, that the clear answer was not at all what you’d expect.

Continue reading The Biggest Mistake Static Analysis Could Have Prevented

How to Add Static Analysis to Your Development Process

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.

If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

Continue reading How to Add Static Analysis to Your Development Process

Static Analysis for Small Business

I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business.  I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.”  But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.

And, since that is a perfectly reasonable question, I bit my tongue against the snark.  I gave a short answer – more or less of “yes,” but it got me thinking in longer form.  And today’s post is the result of that thinking.

I’d like to take you through some differences between small and large organizations.  And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.

Continue reading Static Analysis for Small Business

siemens logo

How Siemens Healthcare manages over 500 million lines of code – An NDepend Case Study

Siemens Healthcare produces imaging equipment for the medical sector in a variety of fields and is based in Germany. Looking to reduce development costs on the next generation of medical imaging equipment, Siemens decided on a platform approach. They have been kind enough to share what they did in an NDepend Case Study.

This brought forth three specific challenges for the company:

  • How can we guarantee the stability of APIs?
  • Can we even make a breaking change?
  • How do we guarantee quality over builds?

Continue reading How Siemens Healthcare manages over 500 million lines of code – An NDepend Case Study

calculating ROI of NDepend

Calculating the ROI of NDepend

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.

Continue reading Calculating the ROI of NDepend

Why Should Managers Care About Static Analysis?

I’d like to talk a bit today about how, if you’re a dev manager for a team or teams that are responsible for .NET code bases, NDepend will help you lower your blood pressure and sleep better at night.  But first, bear with me as a I introduce and explain myself a bit.  It’ll be relevant.  I promise.

There’s been a relatively unique fluidity to my career, particularly in recent years.  The first 10 years or so of my professional career featured somewhat of a standard path from developer to management, with milestone stops along the way earning me designations like “senior” developer, team lead, and architect.  At the end of my salaried career, I had earned myself a CIO role, presiding over all development and IT operations for a company.  And, while I enjoyed the leadership responsibilities that came along with that sort of role, I ultimately decided to go off on my own into consulting, where I’d have more variety and a more fluid set of responsibilities.  These days, I do a combination of development coaching, management consulting, and content creation to earn my living.

The reason I mention all of this is that I’ve had success as a developer, architect, manager, and consultant to all of the above, and that multi-disciplined success has given me unique perspective on the interaction among those roles.  It’s shown me that, above all, what you need to be successful is the ability to trust your dev team.  But trust doesn’t come easily.  You didn’t get to where you are by blindly trusting anyone who tell you a pleasant story.

Here’s your essential conundrum as a manager.  You’re managing a team of intelligent humans that are doing things you don’t understand.  You can protest and claim to understand what they’re doing, but you don’t.  I learned this in my travels as a manager, even managing a team of .NET folks who turned to me to answer their toughest technical questions.  I may have had years and years of professional development on them, but I wasn’t there in the weeds with them, dealing with the challenges that they were, day in and day out.  I had to trust them because keeping my nose in their affairs didn’t scale.  So no matter how well you might understand the surrounding technologies and principles, you don’t understand what they’re doing at any given moment.

There’s a tendency toward entropy that kicks in when you’re managing people whose labor you don’t understand.  A lot of managers in this situation have to fight a panicky impulse to regain control via micromanagement.  I can’t really tell if they’re making good decisions in their coding, but I can make sure they’re getting in no later than 9, leaving no earlier than 5, writing at least 100 lines of code per day, and keeping unit test coverage about 90%.  You may laugh, but it’s a natural impulse, particularly in the face of a slipped deadline or low quality release.  The C-suite wants answers, and you’re caught in the middle, scrambling simultaneously to provide them and to figure out how to prevent this in the future.  You didn’t get ahead in your career through passivity, so the impulse is to seize control, even if perhaps you realize it’s a misguided impulse.

NDepend provides help here.  It allows you to keep an eye on metrics that aren’t obtuse if you structure things right.  I cannot overemphasize this caveat.  Renowned systems thinker W. Edwards Deming once explained that, “people with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it.”  Translated into our terms for this post, what this means is that if you measure your team’s productivity by them producing 100 lines of code per day, they will produce 100 lines of code per day, even if it means creating unstoppable death stars of terrible code.  So disabuse yourself of the notion that you can use this tool to evaluate your developers’ performance, and understand instead that you can use it to identify potential trouble spots in the code.

Pair with a developer or your team’s architect, and use NDepend’s phenomenal reporting capabilities to create a big, visible report on the state of your team’s code.  Here are some ideas for things that might interest you:

  • Which sections of the code are most heavily depended on, so that I can have a heads up when they are changed?
  • How coupled is a module to the rest of the code base?  So, for instance, if I wanted to swap in a new database solution, how hard would that be?
  • Are the most troublesome areas of the code base getting worse, staying the same, or improving?
  • Is the team’s development practice generally in line with commonly accepted good ideas?
  • What does the architecture of the code actually look like (as opposed to some design document that was written and may be out of date)?
  • Are there currently any code violations that the team has identified as critical mistakes?

When I was managing teams, I certainly would have been interested in the answers to these questions for strategic planning purposes.  How dependent you are on a database or whether a feature implementation has touched a dicey section of the code is valuable information for making important decisions (maybe it’s not worth considering a database switch and maybe we should add in more testing than usual for the upcoming release).

Not only can NDepend give you this information, but it can be integrated with your build to furnish it in a very clear, easy, and visible way.  Picture it integrated with your team’s build and delivered to your inbox in digest format on a daily basis.  This is possible to do with your build tool — you could work with the developers on your team to design a build customization where you can see if an area of the code is getting worse or how much coupling there is among the modules in the code.

Imagine it.  Instead of wondering whether your developers are actually working and whether they’re making good decisions, you can partner with them to keep you in the loop on important characteristics of the code, and also to keep you out of their hair for the details it’s better for them to worry about.  You get your information and early detection scheme, and they benefit from having an informed manager that asks intelligent questions only when it makes sense to do so.  And for you, that all adds up to better sleep and lower blood pressure.

Static Analysis : Code as Data

A lot of programmers have some idea of what static analysis is, as least superficially.  If I mention the term, what pops into your head?  Automatic enforcement of coding standards?  StyleCop or FXCop?  Cyclomatic complexity and Visual Studio’s “maintainability index?”  Maybe you’re deeply familiar with all of the subtleties and nuances of the technique.

Whatever your level of familiarity, I’d like to throw what might be a bit of a curve ball at you.  Static analysis is the idea of analyzing source code and byte code for various properties and reporting on those properties, but it’s also, philosophically, the idea of treating code as data.  This is deeply weird to us as application developers, since we’re very much used to thinking of source code as instructions, procedures, and algorithms.  But it’s also deeply powerful.

When you think of source code this way, typical static analysis use cases make sense.  FXCop asks questions along the lines of “How many private fields not prepended with underscores,” or, perhaps, “SELECT COUNT(class_field) FROM classes WHERE class_field NOT LIKE ‘_*’”  More design-focused source code analysis tools ask questions like “What is the cyclomatic complexity of my methods,” or, perhaps, “SELECT cyclomatic_complexity FROM Methods.”

But if code is data, and static analysis tools are sets of queries against that data, doesn’t it seem strange that we can’t put together and execute ad-hoc queries the way that you would with a relational (or other) database?  I mean, imagine if you built out some persistence store using SQL Server, and the only queries you were allowed were SELECT * from the various tables and a handful of others.  Anything beyond that, and you would have to inspect the data manually and make notes by hand.  That would seem arbitrarily and even criminally restrictive.  So why doesn’t it seem that way with our source code?  Why are we content not having the ability to execute arbitrary queries?

I say “we” but the reality is that I can’t include myself in that question, since I have that ability and I would consider having it taken away from me to be crippling.  My background is that of a software architect, but beyond that, I’m also a software craftsmanship coach, teacher, and frequent analyzer of codebases in a professional capacity, auditing a wide variety of them for various properties, characteristics, and trends.  If I couldn’t perform ad-hoc, situation-dependent queries against the source code, I would be far less effective in these roles.

My tools of choice for doing this are NDepend and its cousin JArchitect (for Java code bases).  Out of the box, they’re standard static analysis and architecture tools, but they also offer this incredibly powerful concept called CQLinq that is, for all intents and purposes, SQL for the ‘schema’ of source code.  In reality, CQLinq is actually a Linq provider for writing declarative code queries, but anyone that knows SQL (or functional programming or lamba expressions) will feel quite at home creating queries.

Let’s say, for instance, that you’re the architect for a C# code base and you notice a disturbing trend wherein the developers have taken to communicating between classes using global variables.  What course of action would you take to nip this in the bud?  I bet it would be something annoying for both you and them.  Perhaps you’d set a policy for a while where you audited literally every commit and read through to make sure they weren’t doing it.  Maybe you’d be too pressed for time and you’d appoint designated globals cops.  Or, perhaps you’d just send out a lot of angry, threatening emails?

Do you know what I would do?  I’d just write a single CQLinq query and add it to a step in my automated team build that executed static analysis code rules against all commits.  If the count of global variable invocations in the code base was greater after the commit than before it, the build would fail.  No need for anger, emails or time wasted checking over people’s shoulders, metaphorically or literally.

Want to see how easy a query like this would be to write?  Why don’t I show you…

That’s it. I write that query, set the build to run NDepend’s static analysis, and fail if there are warnings. No more sending out emails, pleading, nagging, threatening, wheedling, coaxing, or bottleneck code reviewing. And, most important of all, no more doing all of that and having problems anyway. One simple little piece of code, and you can totally automate preventing badness. And best of all, the developers get quick feedback and learn on their own.

As I’ve said, code is data at its core.  This is especially true if you’re an architect, responsible for the long term health of the code base.  You need to be able to assess characteristics and properties of that code, make decisions about it, and set precedent.  To accomplish this, you need powerful tooling for querying your code, and NDepend, with its CQLinq, provides exactly that.