« What's the best answer? | Main | Surviving That First Meeting »

Immovable Objects

There are many things that we treat everyday as immovable objects. Immovable? More correctly, they are things that we believe to exist in a particular context, and to always exist in that context. We see Mount Rushmore and quickly -- unconsciously -- put it in the context of South Dakota, the United States, or perhaps in the movie 'North By Northwest'. We see hula dancers, and unconsciously think of Hawaii. We see steamboats going along a river, and unconsciously think of the Mississippi, Missouri or perhaps the Ohio rivers, maybe we think of Mark Twain or 'Showboat'.

We make these cognitive leaps because we have become accustomed to certain signals in the data -- in this case, visual data -- that trigger assumptions about other related things we know.

When we are dealing with data, software and even business processes, we often make these same unconscious leaps. They are unconscious because we don't recognize that we are making the connection. And because we don't recognize that, we don't challenge it or demand proof of its validity, we don't question it. We make the leap and move on.

That's a reasonable thing to do in most cases. Challenging every assumption would waste an enormous amount of time, become extremely tiresome and tedious and annoying, and cost a lot of money.

Fair enough. We don't challenge obvious things. But we need to always be prepared to discover that the obvious connection is invalid. We must always be prepared to discover that some unquestionable belief is in doubt -- in fact, that it is wrong, and that it is leading us to make bad decisions.

Case in point -- telephone numbers.

Some years ago, the United States telephone system adopted the concept of an "area code". This 3-digit prefix to the US phone number (which, by then, was standardized on a 7-digit number format) was assigned to specific geographical areas of the country. Hawaii's area code was 808. Michigan had three area codes (517, 616 and 313). Other states, and Canadian provinces, got their selection of area codes.

Over time, as populations grew and telephone usage became more concentrated, the number of area codes expanded. High-density areas were divided into two area codes, then divided again, and yet again, as population -- or more specifically, as telephone usage -- grew. In my case, over the course of 35 years, I have lived in three different area codes, yet neither I nor my phone moved.

In due course, the area code became recognized as an indicator of not only your telephone number but -- more interestingly -- an indicator of your location. Your phone number starts with '212'? You're a New Yorker. '415'? San Francisco Bay Area. '313'? Detroiter. '312'? Chicago.

Enter the profilers and aggregators. Given a 10-digit phone number, we can now derive your location. From your location, we may be able to infer something else about you -- your demographic, your interests (downhill skiing if you're in Colorado; surfing in Southern California; theater if you're in New York; country music if you're in Nashville). A small piece of data intended to make the phone numbering system more manageable is now revealing something about you -- because we made the (now unconscious) leap from area code to location to probable interest.

Enter the mobile phone.

Before the entry of the consumer mobile phone, a telephone number was associated with a location. It was in my house at a particular address, or in an office in a particular building, or even in a phone booth on a particular street corner. The phone number pointed to a physical, geographical location. Thus it was completely reasonable to jump from phone number (specifically, area code) to location, and from location to interests.

But the mobile phone has no location. It moves from place to place. It is -- what's that word? -- right, it's "mobile".

With the mobile phone, you can't make any assumption about its location at a point in time. However, you can still make an assumption about the owner of a mobile phone. People will buy a mobile phone at a store near their home. That store will assign a number based on its location which is likely to be "close enough" to the customer's regular location. So, for a time, the assumption is safe, though a little shaky.

Enter the ability to "port" your landline phone number to a mobile phone.

In time, those phone numbers that did have a physical location -- your landline phone number -- became mobile. It was possible to replace a landline with a mobile phone, but keep the number. And, of course, the mobile phone was mobile, so a mobile phone with a landline phone number made that landline phone number mobile as well.

Suddenly, phone numbers which were reliably associated with a location became disassociated. In my case, I have a phone number that had been a landline in a location 5,000 miles away from my home. Beyond that, I took my mobile phone to a third location -- neither my home nor the original location of the phone number -- for an extended period of time.

Needless to say, the systems and users who had already made the phone number-to-location assumption did not change their assumptions. The 5 or 6 hour time difference between my phone number's apparent location and my actual location created some particular annoyance -- that telemarketing call at dinner time became a call waking me up at midnight. When the charity was scheduling a route to pick up discards in "my neighborhood", I would get a call asking if I had a donation to put on a porch 5,000 miles away. And -- this is, after all, election season -- the robo-calls would wake me in the middle of the night to urge me to vote for someone who did not represent me in any government.

Immovable objects sometimes move. That's the obvious lesson.

The more important lesson goes to our readiness to recognize that an assumption that served us well in the past has begun to fail. If we are ready for that shift, then we keep careful track of the assumptions we've made; as importantly, we keep track of the conclusions we've drawn that are dependent on those assumptions. When the shift comes, and the assumption must be abandoned, all the dependent conclusions also have to be adjusted -- either abandoned in turn, or defended on the base of some other known and reliable information.

When we build our software, or our data, models, we usually base the model on the business rules that we are given. It is nonetheless our responsibility, as software architects and data architects, to be vigilant about inferences, assumptions and conclusions that are built on convention rather than on a solid and lasting characteristic. If we design according to convention or common usage, we have to be prepared for that convention to be discarded, and with it, significant portions of our design.

Software Metaphysics calls for the careful vetting of all assumptions, all inferences, all derived information and practice that may -- however reliable it may seem at the time -- be one day relegated to the dustbin of history.


TrackBack URL for this entry:

Hosted by Yahoo! Web Hosting
[ Yahoo! ] options

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)