The curious case of if-then-else

Posted on July 20, 2012 by

0


if-then-else control structures were the most curious and fascinating concept I ever encountered in my early programming days. At the time I was a rather impressionable 11-year old hacking away at a ZX-81 first, a TI-99/4A later, and a CDC 171 (COMPASS anyone?), before discovering the joy of Apple. Still it was an awesome concept: computers could make decisions based on simple rules in anticipation of certain outcomes.

Fast-forward some 30 years (give or take; mostly give). I am in my hotel room a day before flying to Chicago, when I get an email from the airline. You may now check-in online for your flight, the message said. Duly, I followed the link to check-in. Sorry, said the website, this is an international flight and you cannot check-in online; see an agent at the airport 3 hours before your flight.

The airline programmers who developed this application knew how to use control-structures. When I went to the website to check-in as instructed, some control structure determined that I was not supposed to be doing so. The decision information was available to the program; the programmers did not use the information at a more optimal time.

Optimal time of course is a relative concept. Maybe the control structure was employed at an optimal time for the programmer. Certainly it was not optimal for the end-user. In my opinion, the control structure should have worked as follows:

if (there are any reasons that the passenger
cannot check in online) then {

send an email reminder to passenger about flight
along with instructions for check-in at the airport}

else {

send an email inviting passenger
to check-in online}

In the example above, the airline has access to all the data necessary to make a decision. It’s a matter of timing which, in my opinion, is a matter of quality design and quality control in the software development process.

There are cases where the system does not have the information necessary to make a decision. Again it’s a matter of timing. Consider the following steps that my bank goes through to cash a check using an iPhone’s camera.

  1. Login
  2. Select “Deposit” from menu
  3. Take picture of front side of check
  4. Take picture of back side of check
  5. Enter the amount of check
  6. Based on the amount allow the deposit to proceed or reject.

Taking pictures of the check is the most time consuming part of the process.

You see where I am going with this. If steps 5 and 6 above were further up the process, specifically after the second step, end-users would be spared frustration and a lot of wasted time.

What is your experience with poorly timed decision making in computer applications? Can you share examples?

As a computer professional, what do you think should be done to improve timing and, thus, productivity and usability?

Advertisements
Posted in: Leo's