My Code is Great! Look at These Numbers!

See, the nasty thing about metrics is that as soon as you start measuring a system, you start changing it. It’s the Heisenberg Uncertainty Principle. Apparently studies have been done that indicate that in successful, maintainable, long lived applications, the average length of methods was 10 lines (I believe this number was derived from Smalltalk applications, but we’re arguing this particular number because we don’t have numbers for Ruby at the moment— this info is also second hand, so we can assume for the sake of argument it’s just arbitrary). The argument is now that we should try to keep our methods to no more than 10 lines, because going above 10 lines means we’re doing something wrong.

I have issues with this mentality. To wit:

1. If I have more than 10 lines, and I am encouraged to rethink my method until it is below 10 lines, should the same argument also apply to methods that are fewer than 10 lines? Logically, it should, but this is never said.
2. What counts as a line? Whitespace? end? Does things.uniq.sort.map(&:to_s) count as more of a line than options ||= {}? Should I write more dense code so I can get more lines into a method?
3. 10 is an average. I have a lot of methods that are 1 or 2 lines. Doesn’t that mean I can have a few 30 line methods without running afoul of the average? I would hope (and assume) that the projects used in the study had them… or the 10 figure would never have been reached.
4. As soon as number get placed on projections of goodness, people immediately try to game the system, as Tammer pointed out in a discussion yesterday, even if the benefit of such is the other developers thinking you have good code.
5. Following the numbers is pointless as you mimic the symptoms and not the cause. Other successful projects had (averaged) 10 line methods, so we should, too! does not make your code good, simple, elegant, or maintainable. In fact, if you hold to the numbers for the sake of holding to the numbers, you’ll probably find a whole lot of WTFs that arose because you didn’t care what you were doing, but how you looked while you were doing it.

One of my biggest problems with the practice is that it takes the art out of coding. If you want a coder to make smaller methods that do less and are easier to read, tell him that, don’t tell him to make the methods 10 lines or less. The number conveys the means, not the end, in this case, and that means the message is lost. You want smaller methods to mean more maintainable code, not simply shorter methods. By focusing on the numbers, you remember the what but forget the why.

Conscious or not, once you start taking metrics, and placing any kind of value judgment on them, you will find that your team will start to value the metrics more than they value writing code that’s good for the sake of being good. I argue against taking or caring about metrics at all, because while some proponents suggest that you take metrics and then not care about them, I don’t think that’s really possible. Once metrics are taken, coders will want to improve them. I can hardly blame them; any good coder will invariably want to get better. But like the problem with Amazon’s Mechanical Turk, coders will change their reward from writing good code to writing code with good metrics.