Michael Feathers

Prosthetic Goals and Metrics That Matter..

I'm not quite sure why, but I've been hearing a lot of code coverage horror stories recently.  It's great that people are discovering that automated testing is good, but you can't measure quality with coverage.  Yes, coverage does give you a measure of effort.  It does, after all, take effort to get coverage numbers up, but sadly it's possible to get a lot of coverage that doesn't do you much good at all. 

Brian Marick wrote a wonderful paper about code coverage misuse (pdf).  I won't repeat his points here, but the one thing that I'll add is that coverage is a particular lousy measure of a quality effort because ultimately you want the team to pay attention to quality, not numbers.  The numbers might tell you something about quality, but it's dangerous when they start to become a goal rather than the means to a goal.  It's hard to hit one target when, in reality, you're aiming for another one.

I used to call this sort of thing a surrogate goal until Tim Ottinger came up with a better name: prosthetic goal.  A prosthetic goal is something that you hold up as the goal when you want people to achieve some other goal that you can't measure easily.  Want employees to produce more value, add an incentive program.  Want people to work with quality?  Adopt ISO9000.

Sometimes prosthetic goals and your ultimate goals dovetail nicely, but at other times they don't.  There's a gap.  You can spend so much time working on the prosthetic goal that you lose on other fronts.

Want to improve quality?  Then measure quality.  Measure bug count.  Or better yet, measure delays that are due to bugs and try to reduce them.  Time is money after all, and that's money down the drain.

Speaking of wasted time..  I'm hoping that I run into a team someday that measures average build time on developer's machines.  How long does it take for each developer to get feedback whenever they hit the compile button?  There are many teams that could work a lot faster if it didn't take them so long to compile.

Dealing with a Special Boundary

Every once in a while, I run into a problem with collections.  I have some operation that I need to do with all of the elements, but I need to treat the first or the last case differently.

Typically when I see see people attempting to do this, they handle the special case:

if(words.length > 0) {
    result += words[0];
}

and then loop over the remaining elements:

for(int n = 1; n < words.length; n++) {
    result += ", " + words[n];
}

That's one way of doing it but it's a pain, and it does make you wish for blocks and open classes so that you can write this sort of code once, add it to your collection classes and then never have to deal with it again..   but I do most of my programming in old school languages so sometimes I do something like the following:

for(int n = 0; n < words.length; n++) {
    result += (n == 0 ? "" : ", ") + words[n];
}

You may not want to do this if you're working on something that is performance critical, but it is a handy little idiom.

Andragogical Challenge

I'm in Poland right now, and I just got back to my apartment after a long day of teaching.  I never thought I'd enjoy teaching as much as I do; I've always been a bit of a loner, so standing in front of a group of people was something that I had to work at.  But, one thing that I've noticed over the years is that the best way to get interesting insights into an area of design or practice is to teach it.  Often when you're in front of a group of people, reaching for an explanation, you find it. 

It's not all fun, though.  One of the things that I battle constantly is something that I call androgogical challenge.  Andragogy is an interesting word.  Many people don't realize it, but the root of the word pedagogy is ped, which means children.   Andragogy is the corresponding  word for the study of adult teaching.  Adults learn differently, and some of our quirks, as adults, trip me up. 

What are the quirks?  Well, one of them is the need to relate to experience.  When you're attempting to help people learn something in programming, choice of examples is critical.  Unfortunately, it is very hard.  If you pick something too easy or too stylized, some people will see it as a "toy example" and "turn off."  They can't imagine how it relates to the work that they do.  If, on the other hand, you choose something which is very realistic, you can end up with overload.  It is hard to highlight the important points in a sea of detail.

So far, I haven't found any set way to tackle this problem, but I know that I constantly have to be aware of it when I teach and when I write.   Examples have to be detailed and realistic enough to engage, but also fertile with interesting decision points.  But, if you supply too much detail you can end up derailed, dealing with points that don't really have as much bang for the buck.  It's a hard balance.

Beautiful Code: Released!

A while back, Greg Wilson and Andy Oram approached me to contribute to a book called Beautiful Code.

It's a collection of chapters about code that exemplifies our craft; the sort of code that you'd point students and newcomers to if you wanted to show them what's important in software today. 

I took the opportunity to write a chapter about Ward Cunningham's FIT framework, and I'm glad I had the opportunity.  There are some sublimely beautiful things about FIT.

I've recently started to blog over at the Beautiful Code website.  Over the next few months, I'll be over there with a bunch of other people trying to draw out and nail down the notion of beauty in software.   Come over, if you get a chance.