Code quality metrics are king

If you want to induce a bout of anger and depression, run a tool like NDepend on your codebase (or Resharper’s code analysis, or VS2010’s code metrics, or any other similar tool).  I would guess, if you’re a competent developer who knows what ‘good code’ looks like, you’ll find a few things:

1. The areas that you knew were problems show the worst.
2. The areas that you think are good code have good quality ratings.
3. Your dependency graph is a mess.
4. The number of problems overall is so large it is debilitating to think about and hopeless to try to fix.
5. The number of problems in areas people don’t think are problems will put you into a rage.

This has been my experience, at least.  Code quality in most places is pretty crappy overall, and it isn’t uncommon to find the official practices are not what they should be- yet they are vigorously defended.  Code quality metrics provide an unbiased, unequivocal judgement on specific pieces of code, and the codebase in general.  Metrics can be gamed, but I’d much rather have a codebase that has good quality metrics than one that doesn’t.

Running the analysis is the first part.  Fixing the problems is the last.  The real challenge is inbetween: the why and how of fixing the problems, and not just from a scheduling perspective.  The difficulties involved in creating a plan to improve code quality are less technical and more difficult, and I’ll go into some potential strategies in a future post.

Also, if you want a quick tutorial for running Visual Studio’s Code Metrics, take a look at Zain Naboulsi’s Visual Studio Tips and Tricks blog is this thing on?.  He recently  finished running a few posts about using Visual Studio’s Code Metrics tools.  And if you want to do some serious codebase analysis, of course take a look at NDepend.