---
title: My Code is Great! Look at These Numbers!
teaser:
tags: analytics
author: Jon Yurek
published_on: 2007-04-13
---

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][heisenberg]. 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.

[heisenberg]: https://en.wikipedia.org/wiki/Uncertainty_Principle

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.
1. 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?
1. 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.
1. 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.
1. 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.

[WTFs]: http://worsethanfailure.com/

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][mech-turk],
coders will change their reward from writing good code to writing code with good
metrics.

[some proponents]: https://blog.codinghorror.com/a-visit-from-the-metrics-maid/
[mech-turk]: https://blog.codinghorror.com/is-amazons-mechanical-turk-a-failure/