You’re Ugly and Your Code Is, Too
Ask any development manager how their coding practices stand up against “average” and they will likely say, “Sure, there are things we could improve, but we are as good as (or better than) average.”
This response is known as the Lake Wobegon effect, after the fictional town in the Garrison Keillor radio series A Prairie Home Companion where, he opined, “all the children are above average.”
A 2005 article in the New York Times found when investigating an online dating service that only one percent (1%) of the population admitted to having “less than average” looks.

Funny and interesting, but what does it mean about your code?
Psychologists tell us that, especially in areas we consider important, we have poor skills at “comparative ability.” If tasks are important to us - whether we consider them easy or difficult – we respond with empirically illogical numbers: 75% - 90% of us claim to be “above average”.
This, of course, is especially true with subjective measurements. Asking someone how good-looking they are is a different exercise than asking how their weight compares with others who are the same height – especially if you first provide them with a scale and an actuarial chart of average weights.
As we self-evaluate our own capabilities in the important area of code (and code quality), we must recognize our own vulnerability to the Lake Wobegon effect. A great way to accomplish this is to move from the subjective to the objective.
Analysis of cyclomatic complexity, code duplication, code dependency and test coverage are objective measures that can provide meaningful, actionable information about how well our coding practices actually work. Without an objective score, you cannot measure your progress. And, as Bill Hewlett (HP) stated, “You cannot manage what you cannot measure.”
Once you have objective measures, seek out comparables within your organization and/or your industry to see how you truly fare against relevant averages.
But the real value is not in actual comparables, it is in avoiding the negative impact of our own common weakness of comparative ability and transforming our self-analysis from the subjective world to objective measure.
For the record, I don’t think you’re ugly. And, for those of you who are even more offended by the latter statement (you know who you are), I don’t think your code is ugly either.

October 27th, 2006 at 10:05 am
[…] You’re ugly and your code is, too- Burke Cox doesn’t miss a beat to tell you how he feels. […]
October 27th, 2006 at 1:41 pm
It’s actually quite possible to have 99% of a sample set be above average. For example, in {1, 10, 10}, 67% of the elements are above average.
October 30th, 2006 at 9:48 am
Mr. X - Sure, but we are expecting a normal distribution from a large sample set. You could say that it is actually quite possible that 99% of people I meet on the street would be named Joshua. For example, in {”Jill”, “Joshua”, “Joshua”), 67% of the people are named Joshua. But these contrived examples do not reflect the reality of a large sample set.
October 30th, 2006 at 12:17 pm
No, you’re still missing the point because you are confusing average and median. Check out your friendly wikipedia for a brush up.
Only in exceptional cases will exactly 50% of a sample set be above the average.
Try it: generate 100 random sets of 100 values each and see how often exactly half of them are above average and the other half, under.
October 30th, 2006 at 12:40 pm
You are correct in distinguishing mean and median, of course. I felt it was worth ignoring in this case because we’re not investigating a set that would contain material mathematical outliers…so mean and median would lie close together assuming a normal distribution.
October 30th, 2006 at 10:00 pm
X makes an excellent point. I would say that something like 75% - 90% of software shops have “ugly” code.
May 24th, 2007 at 9:36 am
I’d go so far as to say that 100% of shops have ugly code — sooner or later, you’re going to do something non-idiomatic in your language of choice, and that means you’ve got some ugly.
The important question is how *much* ugly code is kicking around…
May 24th, 2007 at 10:02 am
I’d agree with that. That’s where running automated inspections (static/dynamic analysis) as part of a CI system can provide a way to shine the light on those areas so that developers can improve the areas that make sense.
June 8th, 2007 at 12:37 pm
[…] A client I worked with recently had a very astute characterization of Continuous Integration. I will paraphrase it as “CI is a reflection of reality”. He was referring to the immediate feedback you receive from a successful or failed integration build. Using a single source (your version control repository), you’re able to quickly determine if any of your recent changes “played well with others”. Not tomorrow, not two weeks from now, but immediately after a change is made. It reminds me of something Bill Cosby used to say in one of his stand-up routines when someone mentioned they liked using cocaine because it “…intensifies your personality”. Cosby’s response was “Yes, but what if you’re an a**hole?”. CI provides you with a mirror of your software under development. It’s not the fault of CI if it comes back and tells you your code is not working as intended. If fact, you should embrace it before it tells you it’s ugly. […]