On Sunday My Wife Was Awesome!

She completed the San Diego Rock and Roll half marathon (13.1 miles) in 4 hours 7 minutes and 10 seconds. Despite a hurt foot and a pulled leg muscle she was determined to be a winner — and she was a winner. A big thank you to everyone who donated and offered words of encouragement. I couldn’t be more proud of her. She was able to walk the next day amazingly, and by this morning she was feeling almost back to her normal self.

The Boolean and its Shades of Gray

The following is just a pretty much unedited rand()m musing from my brain. It could be wrong and I may decide later that I don’t agree 🙂 What do YOU think?

As programmers/developers/engineers we, collectively, cling to our various security blankets. You don’t like ruby because its just a bunch of kids goofing off; you don’t like java because its a bunch of stuffy old geezers who spend more time typing god awful paths than creating; you don’t like PHP on principle. You prefer windowx/osx/linux. Vim or emacs or editing files by hand using small magnets and an electron microscope. Whatever it is, whatever your justifications, you have them (admit it.)

Some of our security blankets are fairly personal: I like my coffee a certain way in the morning. And some are pervasive. Today I want to harp on one of our pervasive security blankets for a bit.

The boolean.

You could say that any man who is too quick to answer yes has not yet come to fully appreciate the question, likewise any man who is quick to answer no has not even bothered to consider his options. We ask yes or no questions of our programs all the time, and we take the answers we get as gospel.

But are they?

Sometimes the answer really honestly is clear cut. 1 === 1? Yes. 1 === 2? No. Easy. I am not questioning these (though even this can be argued at varying levels of floating point precision depending on your platform and/or toolset.)

Now days most of us are writing parallel systems, or for them. Don’t believe me? Okay. Everyone who’s written any program in any language for the web that runs on any web server capable of handling requests in parallel — raise your hand. So, yeah, most of us write or write for parallel systems these days.

And yet we persist in asking our programs things like this:

Is the user Joe currently active on the site?

This seems like a simple question. Generally the way we answer this is by keeping a timestamp of the last time we got a request from Joe… somewhere. Then we program our response to this question based on how long ago that timestamp is compared to right now.

So when you ask whether Joe is currently active, you get whether he recently did something. You don’t get whether Joe is looking at the site right this second. Even if his last activity timestamp matched, to some arbitrarily significant decimal digit, you don’t know whether his browser is open NOW, whether he’s looking at the tab NOW, whether Joe is still even alive.

We, as programmers return a boolean answer – “yes”, when we really mean “maybe,” or “probably.” This isn’t a problem in and of itself. But as the developer of your application you need to understand when “yes” means “probably,” and “no” means “unlikely.” And you should be clear about when this is the case in your naming conventions, your comments, and your documentation.

The more time you take to understand these gray areas the more robust your programming will be. You’ll be better able to spot things like race conditions, and faulty logic. But more than that the simple act of being honest about the “state” of your application and all of its various pieces in relation to each other including the amount of uncertainty surrounding that state is profound. You can learn to control, and handle, the uncertainty that exists. You can benefit from the uncertainty. You can decide to be certain in one area by sacrificing certainty in another.

Remember that the computer does what we tell it. We tell it what we decide. We decide based on what we know. And if what we allow ourselves to know is corrupt. Well. It doesn’t take a GOTO statement to see where this is going.