Yeah, I know you could tell from the title, this is a

<rant type=philosophical>

Last weekend I checked in a change to the Aperio Image Library (AIL).  It was a “refactoring” change; I moved the cropping logic formerly found in one class into another.  So anyway I made this change…

… and it worked!

And that would be the end of this story and not worthy of a blog post, but I discovered a fug.  A fug is a feature which is so lame as to be indistinguishable from a bug.  I'll spare you the details, but it had to do with thumbnails, and it ended up that a thumbnail was returned, but it was too small to be usable.  A fug.

Okay, so what to do?  There was a design choice to be made, and I made the wrong one.  I spent a whole week debugging the resulting code, which broke in about four directions because of my choice.  In retrospect it was apparent immediately that my design choice was incorrect.  I should have applied W=UH, realized that U was too high, and stopped.  But I did not.

{
For those who don’t know, W=UH is the universal equation of life, which holds that:

Wrongness = Ugliness * Hardness

If something is Ugly or Hard, it is Wrong. This was first observed in relation to programming but turns out to be relevant for everything :)
}

Which brings me to “almost famous” design.

One of my favorite movies is Almost Famous, a semi-autobiographical movie by Cameron Crowe which chronicles a 15-year old kid who ends up touring with a just-about-to-make-it rock band.  If you haven't seen it, you should.  Anyway there’s this scene where Cameron is going to a concert, and his Mom drops him off, and as he’s walking away she yells after him “make good choices”, and a bunch of the other concert goers start taunting him with it.  But Mom was right, in life as in programming you have to make good choices.  The consequence of a bad choices is far-reaching and greatness will elude you after that; you will never be more than almost famous.

So, W=UH provides clues when you've made an almost famous design choice, and when this happens you must backtrack and fix the bad choice, or be forever saddled with ugliness, hardness, and wrongness.

In this situation however I ignored the wrongness and pressed on.  And immediately found myself doing “stochastic debugging”. Which is always a sure indication of a bad design choice.

{
stochastic = random, a stochastic process is one in which things are done randomly
}

What is stochastic debugging?  Well, that’s when you “try stuff” in the hope that things will “just work”.  I know you've been there, don’t tell me you haven't.  Here I am in this little thumbnail generation method, and I have all these parameters and class values, and I’m trying various combinations of things hoping to get the thumbnails to generate correctly.  Eventually it worked, for some set of test cases, but then inevitably there was a new test case and it didn't work.  Like balancing a ten legged stool.

I had an Almost Famous design, and I was desperately trying to get it to work.  I even got it to work – after a weeks’ worth of stochastic debugging – and checked it in.  Yay!  And whew.  On to the next problem!

Um, no.  Because then the next morning I made a new change to the library, and it broke the thumbnail logic.

Crud.  I had finally reached the end of a long and winding road.  It was time to backtrack all the way back to that original bad design choice.  This library cannot be almost famous, it must be robust, clean, solid.  No wrongness!

So I went back, all the way back to point zero.  I rethought the entire problem.  Everything worked before, what had I done to make everything break?  Where was the fundamental disconnect?  And I found it.  (The thumbnail is a property of the image, as modeled internally by an object, it is not a property of the view, as modeled by a different object.)  As soon as I had this insight, the clouds broke, the sun shone, and violins began to play.

Anyway I recoded everything, which this time was surprisingly easier, happily deleted about 2/3 of the new code which was no longer necessary, did a little bit of non-stochastic debugging, and now everything works.  I actually did a lot less testing than before because I knew the code was right.  And I checked in the code.  And I wrote this blog post.

So – moral of today’s rant: do not make almost famous design choices. If you find yourself doing stochastic debugging, backtrack and fix the design.

<digression>

A long time ago in the dawn of time, I had an admin (aka secretary).  Back then we didn't have our own computers, we hand-wrote memos and had them typed.  (Yes, I am that old.)  My admin did have a word processor, so she could easily edit stuff.  (No, I am not that old.)

So I wrote this memo which had tables of numbers in them.  I updated it a few times, and every time I changed the numbers, it took my admin hours to update it.  Way longer than just changing a few figures.

I walked over to see what was going on.  She had used spaces instead of tabs to line up the tables of numbers.  An almost famous design.  So every time I changed the figures, she had to screw around with the numbers of spaces between all the columns to get everything to line up.  Stochastic debugging.

I told her to use tabs.  She did, but she thought I was crazy.  From her point of view, it looked the same when it was printed, so what was the difference?  From my point of view using spaces was Wrong.  Sure, it looks the same, sure, “it works”, but it wasn’t right.

</digression>

I think of that memo often, because the same thing happens with code.  Just because code works doesn’t mean it is right.  If you use spaces instead of tabs, it is wrong.  It is almost famous.

</rant>

I have not made the cover of the Rolling Stone.  Yet.  But maybe Dr. Dobbs?