The Completeness of Code

I’ve been thinking a little bit lately about the notion of completeness in programming. I think it’s a valuable concept because those of us who write software have a hard time defining what the word “done” means with respect to our product. The old saw about model railroads is that they are never finished, and I think a lot of us feel the same way about the code we write.

A similarly ephemeral concept is that of correctness. When is a body of code “correct?” Can a given piece of software be “correct” without being “complete”? The problem with correctness is that software is too complex to support any but the narrowest definitions of the term. We could define correctness as the state of development at which a piece of code produces correct outputs for all possible inputs. But it’s difficult to assert that any non-trivial system meets even that fairly specific definition, and that definition leaves out a lot of possibilities for things to go wrong due to external factors.

In practical terms software is perceived to be complete when it does all the big things we asked for it to do. This idea is reinforced by methods of requirements definition such as Use Cases, which focus on large-grained behaviors of actors in the system. I think it’s safe to say that we can get all that stuff right, and yet not have “complete” code.

So what is complete code? I’ll take a stab at a definition: Code is complete when it produces the correct outputs for all possible inputs, and fails safely and gracefully in all possible situations where a correct output cannot be produced. In my experience it’s often that second part of the definition that gets short shrift in the development process. Time and again I run up against code that takes the straightest possible path between input and output, and ignores a slew of potential boundary conditions and failure points along the way.

Putting the blinders on and dashing straight for the finish line is usually defended as pragmatism and a “get ‘er done” attitude, and there are times when it is absolutely a virtue. If you ever do a technology start-up you’ll encounter many of those occasions, often strangely correspondent to meetings with potential investors. But for just about any system that has to actually run reliably and do important stuff in a production context completeness is a more important quality than brevity. Brevity will make you feel good now, but it will cost you in the long run.

Unfortunately completeness is hard to see, doesn’t provide any immediate benefit in the eyes of users, and is therefore something they hate to pay for. Buying an incomplete piece of software is like buying an old, worn out car with a new paint job and refurbished interior. It feels great, and it’s fun to show it to your friends, but step on the gas and the wheels fall off. I’ve seen the wheels fall of a few software systems when the throttle was opened. I guess it’s a lot easier to place a value on completeness when the lack of it means you have to walk.

The Death of Voice Mail

The New York Times had a little technology piece today about the waning popularity of voice mail, and it struck a chord with me. If voice mail isn’t the 8-track tape of the early 21st century communications industry then I don’t know why not. It should be. Voice mail is one of those strange devolving products that has gotten to be more of a pain in the ass over the years, rather than less.

You could probably say that the home answering machine was the first widely available voice mail technology. By and large they were easy to use. You plugged it in, pushed record, said a few words, played them back, pushed record again, realized ten minutes later that you would never sound better than that, and finally gave up and watched Johnny Carson before going to bed. Later when you returned from some extended absence you would know you had messages because the machine was blinking. You pushed play. You listened. You erased.

Which was all too easy for voice mail marketing people to stomach, so they started to add features. Multiple boxes, separate greetings, calling number storage; the slow climb of voice mail up the Rectal Scale of annoyance had begun. Voice mail had become a pain in the ass.

The growth of the cell phone business only made it worse, because along with new features we got lots more prompting. Apparently the explosion of tiny hand held cell phones gave lots of stupid people access to voice mail for the first time in history. I make this admittedly offensive suggestion only because I can think of no other reason why the nice lady insists on repeating 20 seconds of instructions every time I dial in to retrieve my voice mail. Yes, yes, dammit, I recall something about entering my four-digit pin and pressing ‘pound”. How about you shut up now?

Voice mail is a pain in the ass. Email is not a pain in the ass. See how simple technology market prognosticating can be? Skype is also not a pain in the ass, at all. I work for a small software company that has several offices around the country knit together using email and Skype. We have a virtual PBX, with an 800-ish number and assigned extensions for everyone, and last week the owner of the company admitted to me that he couldn’t remember them half the time. When we want to get ahold of each other we email or, far more often, Skype. In fact, I am at my desk so often working on projects that if you call my aging Embarq (Sprint, with a coat of paint over the rust) landline and get voice mail, it’s because I’m on Skype.

Voice mail: it’s as relevant as a cathode ray rube, and as fun to use as a mimeograph. What’s not to love?