Thursday, January 21, 2010

Unexpected, Not Wrong

Yesterday I wrote about some behavior in Ruby that I didn't expect. Basically, I was attempting to use "downcase!" (rather than "downcase") and getting nil if nothing changed. A commenter noted that was intentional and kindly linked to the spec.

Here's how I got into the situation:

I was trying to get an attribute off an object, and that attribute took the form "num_[Type]". I already had the type handy in a variable, but I couldn't guarantee it was the same case as the attribute. So I thought to myself, "Self, this is simple. I'll just downcase it since I know the attribute is always all lower case." Then I said to myself, "Self, I'm not going to deal with assigning variables here; I'll just modify that type in place." So I added a "!" to the "type.downcase" I had already written.

It turns out I was wrong. When it failed and I looked at the rdoc for that method, I found out what I was doing wrong (and removed the "!"). It wasn't a big deal. But it did make me scratch my head.

So... is it a bug?

It was unexpected. However, it was also doing exactly what the implementer intended. Intent isn't everything, but that means it wasn't a simple mistake (aka bug). There are two questions to ask:
  • Is that intent correct?
  • Is that intent expressed to the consumer of the product?
The first question is fairly obvious. Okay, the implementor meant to do that, but is it really the right thing to do? Is it consistent with the remainder of the product? If similar workflows and similar items exhibit similar behavior, then it's probably expected behavior, and that's generally good. Does it meet the consumer's need that it intends to fix? This is the harder part of correctness. The product's consumer is going to do something with this particular feature, and the product needs to allow the consumer to accomplish that need or action. This is generally where your customer or your product management needs to weigh in.

The second question is a bit more obscure. Assuming you've crossed the first two hurdles - intent and correctness of intent - there is a third hurdle of actually letting the product consumer understand this intent. In short, we have to document the behavior. That can be through documentation, code samples, comments, etc. It can also be through simple consistency, conforming to customer's expectations by being similar to something familiar.

No matter what product you're using, you'll occasionally run across behavior that makes you scratch your head. Figuring out if that behavior is a bug revolves around figuring out what was intended, whether that was right, and if the intended behavior is conveyed to the consumer. When you know all that, then you'll know whether you have a bug, or just a scratched head.


  1. This is really cool. You're pioneering a path through the Intentional Fallacy ( and the Principle of Least Surprise (

  2. Chris, I hadn't thought of it at all like that, but you're absolutely right. Information derived from the work itself (in this case code rather than Finnegan's Wake or the like) meets "okay, that's what I expected".