Now, I have some contempt for code metrics, ever since I discovered that TFS thought that my worst code was a constructor that checked its parameters for null.  Metrics are useful indicators.  Profit is a metric used to measure the health of a company.  It's not always useful, but that's the nature of metrics, they're indicators, not hard and fast rules.  I thought it might be interesting to examine Patrick's original post about NHibnerate 2.1 which started the whole recent argument about maintainability. First, he took a look at the number of changes to the code base.  There's been a phenomenal...

I've already talked about Patrick's measures of code quality.  His approach is to take a very direct mathematical and analytical approach to it.  I appreciate the sophistication of the tools he's using, but I think that the results of this kind of analysis need to be treated with the same level of suspicion as an analyst treats a set of accounts.  e.g. Cash flow is hard to fake, but why are the accruals so low? Ayende, on the other hand, argues for a very different approach.  He lists as his measures of code quality: Peer code review (especially...

Did someone declare it "talented developers talk rubbish" week when I wasn't paying attention?  Maybe I wasn't on the mailing list... *sigh* First we had the extremely smart Frans Bouma talking about the importance of proving your algorithms as a development methodology, which at least had the virtue of being funny.  We then had one of the single most productive developers in Alt.Net talking absolute garbage about maintainability.  At least Patrick Smacchia is still talking sense.  Let's go back to what Ayende's saying.  Maintainable is a value that can only be applied by someone who is familiar with the codebase. This...