Saturday, June 25, 2011

Good Architecture, Bad Implementation

I’m not particularly resilient to bouts of insanity as readers of this blog will surely know. I skirt precariously close to the edge of hyper-expressiveness over the simplest topics. For example, just ask me about using production data in QA. Just saying.

I received a voicemail from a vendor who, presumably, wants a call back. I say presumably because they left a return phone number. At least I think it was a phone number. No humanoid audio-receptors indigenous to the genome referred to as Homo Erectus could possibly have deciphered the string of mashed syllables that followed the words "can be reached at …"

I don’t get it - the one single piece of information that is most critical to getting a call back - the phone number - is the one piece of data that is most commonly scrunched up to unintelligible gibberish. I do get this though - the phone number is so well known to the speaker that they can speed-speak it. That’s great for them and their precious cold calling phone time, but it is perfectly useless to the listener.

Again, readers here know of my critical eye when it comes to reader-centric writing, but the same is true for speaking. It doesn’t matter if the speaker knows what’s being said, it only matters if the listener knows. Seriously, I frequently have to replay the end of voicemail messages three, four, and five times, just to catch the phone number. I’ll bet this happens to you too.

Now here’s the rub; Bell Laboratories spent considerable time architecting phone numbers. First, most people make most phone calls within a small geographic area, so (at least initially) area codes could be assumed. Then, the exchange numbers (the set of three digits before the dash) were typically of a small set. For instance, in my neck of the woods the common exchanges are 762, 343, 561, and 563. There are others to be sure, but the vast majority of people I call are in these exchanges.

Lastly (again, not counting the area codes) phone numbers are a total of seven digits long, which fits very nicely in the human brain which has a short term memory buffer that can hold about seven things, plus or minus two. Again, a lot of research and architecture went in to figuring this all out. So, theoretically / architecturally, phone numbers represent a solid design based on the context in which they are used (the human brain). Today, we must deal with ten digits which is not optimal, but still not a bad design, when you consider chunking, and recognition.

All of this incredible thought is worthless to a over-clocked orator that can rattle off an important set of deca-digits faster than a ‘68 Chrysler goes through a tank of gas. Sometimes, you can have a great architecture with a really yuckie implementation. Just because a solution fails in production, doesn’t mean the architecture is at fault. Just because I can’t understand cold calling vendors doesn’t mean that phone numbers were poorly designed.

Consider the architecture when diagnosing production issues, but also be willing to accept that the architecture is sound, it is the implementation that failed.

Follow by Email