Greater Than, Less Than, What’s the Difference?

Thinking big by thinking small

I had a professor once (actually the finest I’ve ever known) who insisted to his students that “programming is all about the little details”. In my view, what he meant by this is that regardless of the project, methodology, people involved, or what-have-you, if the software doesn’t do what it’s supposed to do, it’s most likely the result of someone, somewhere, failing to account for a few little details. Not that those few details are necessarily easy or hard to identify (or rectify)—the point is that tiny discrepancies in code can have tremendous impact.

Case in point: our ship date is nigh, looming upon us like a brick wall in the middle of an interstate. We’re about ready to let this thing out the door, when we discover oops, that module X that we built two months ago, the one that we’ve had the requirements signed off on three separate times, isn’t quite right. Essentially,
Behavior ‘foo’ should result when incoming_date is > existing_date
should read:
Behavior ‘foo’ should result when incoming_date is >= existing_date

There are some additional details which only add to the headache, but I’ll spare you those.

Well, what’s the big deal, you may ask… it’s only one character. Just type an “=” sign, recompile, and move on with yer life, fer cryin’ out loud. Ah, but it’s not that simple. Because all of our DBunit tests (several dozen for this module) were built with the assumption that the first specification was the correct one. They’ll have to be revisited.

Oh, and the systems tests that QA put together and worked liked dogs (fourteen dogs, each one working harder than the one before it) to complete on schedule? They’ll have to be reworked and re-run.

Three days before the friggin’ ship date.

Now, the point of this isn’t to rant, or lay blame. The problem was, after all, the result of someone missing the ramification of one teensy-weensy little character in a mountain of characters. It can, and does, happen to the best of us. No, the real problem isn’t with the people, it’s the fact that flat-file specifications do a poor job of clearly indicating to the reader what the relative importance of each piece of information is.

What do I mean by ‘flat-file’? I mean an organizational structure that simply, and flatly, states facts, not taking into account the way humans process information. A structure that allows matters of vital importance to occupy a single chunk of the document’s real estate. A structure, in short, that reflects the author’s affinity for describing facts to a computer, and not to other people.

I don’t, as of yet, have a good solution to this problem. But I feel like I’ve mad a start by identifying this as a problem. What I want is a way to reliably and, if possible, automatically make important things look important.

Hmm, sounds like a hard problem that could make for a good software product…

Off By One

I was working on some a code a while back and I accidentally added an Off By One error. Then someone else added one.

We inadvertently created and Off By Two error and made the system work *very* hard as a result.

I thought you were going to

I thought you were going to say that if everyone understood the purpose of the equation, rather than just following "flat" orders, they would have discovered the mistake much earlier.

Yeah, but these are tax rules...

...and so there's just a whole mountain of what can charitably be described as "arbitrary" rules. Of course they make sense to someone at the IRS, just not always to us. There just isn't time to understand it all.