If you’re going to be in the Chicago area on or about Saturday, September 20th, you can see me give my “Using Metrics to take a Hard Look at Your Code” talk at the Windy City Rails Conference. David Heinemeier Hansson, David Chelimsky, and Noel Rappin have been announced as speakers and I’ll be joining them for a interesting day of Rails related goodness.

Here’s the abstract:

It’s an interesting fact of human nature that you can’t do something every day and not secretly suspect that you’re good at it. Which goes a long way toward explaining why everyone thinks they write fine code. To combat this self-delusion you can use metrics to take a hard look at your application. This talk will discuss the ways in which you can measure how good your Rails project really is. And how to fix the bad parts.

Using a daily metrics build (run every day by CruiseControl.rb) you can compile a ‘hit-list’ of the worst methods in your application. Then your team can spend some time every iteration trying to refactor these methods.
In my talk I will discuss 4 tools to identify problems:

* Code coverage with Rcov
* Cyclomatic complexity with Saikuro
* Flogging with Flog
* Using source control to figure which files change the most

All of which are pretty easy to use, especially if you use metric_fu – a Rails plugin (blatant plug). Once you’ve figure out where the badness is, you must fight it. While showing examples, I’ll be discussing:

* Why 90% (or even 100%) test coverage isn’t a silver bullet against bugs.
* How Saikuro and Flog measure complexity and the advantages of each.
* When complexity is OK
* Why ‘inject’ sucks, except when it’s pretty cool (see above point).
* Strategies for figuring out if your fancy metaprogramming is worth the extra complexity and what to do if it isn’t.
* What is good enough coverage.
* Failing your build on poor metrics numbers.
* Why you should always remember Carlin’s law:
“Have you ever noticed that anybody driving slower than you is an idiot,
and anyone going faster than you is a maniac?”