Avoiding Frequent Flier Syndrome

Have you ever read through all the materials that the airlines send each and every month to their frequent fliers? I'm not talking about just taking a quick glance at the statement where it congratulates you for storing up another 746 miles, while announcing that the cost in miles of a round-trip ticket to Burbank just went up from 100,000 miles to 100,750 miles. I'm talking about all that other stuff: The great car deal you can get if you fly to Cleveland on a Wednesday and pick up the car at the airport on Thursday—the Pittsburgh airport, that is—with a drop off at the Holiday Inn in Grand Rapids, with a mandatory three-night stay therein, Saturdays included except during certain blackout periods, including the span from the time you were born until the time you die. Those frequent flyer materials.

Who writes these things? They obviously believe that we have nothing better to do with our pitiful lives that to wade through this trash looking for the "kickers," those delightful little "oh, by the way"s that invariably result in our being better off tossing the whole thing and paying a la carte for first class on the Concord.

After a while, we learn the only reasonable thing to do is to throw everything away except for that sad little statement. And many of our users are learning the same thing.

A Plain Horse and Wagon on Mulberry Street

Commercial ventures turn to computers for performing existing tasks for the purpose of either saving money or making money. For the purposes of this article, let's ignore all those software e-ventures dedicated to making money and just concentrate on saving.

In the Dr. Seuss tale of the Plain Horse and Wagon on Mulberry Street, the little boy is expected to tell his family of all the sights he sees on the way home from school. On the day in question, all he sees is the aforementioned horse and wagon. However, he figures such a simple sight will not do so, during the course of the story, he adds on more a more bits and pieces to his "recollection." By the time he arrives home, he was prepared to report a wondrous sight including several different circus animals, a grand wagon driven by the mayor, and a parade of scantily-clad lovelies dancing alongside—um, that's the way I remember it, anyway.

Software projects tend to grow along these same lines, with each round of brainstorming layering the design deeper and deeper in complexity. Several different roles and forces add to the tumult.

The Client's Part

Clients will seek out a software house, flush with the hope of cutting radically back on the expenses of their current paper systems. Then they will often turn around and do their very best to crush any hope of achieving that dream.

Let's assume our client makes widgets. For the last hundred years or so, customers have called up or mailed in for all their widget needs. Order takers have written up the orders, then, periodically, taken the orders to the warehouse for fulfillment. Let's also assume that there is a computer solution that will enable the client to save money through increased efficiency, etc. So what is a client's part in screwing it up? In my experience, it has always been creeping features. The client wants more features in order to gather more information and to exercise more control.

Our widget maker starts out just wanting a very simple order-entry system, with the results showing up as shipping manifests, bills of sale, and labels in the shipping department. But then they get to thinkin'. Pretty soon, they realize that they've never really known why their customers are buying these widgets, and, if they did know, they could turn out widgets that were more responsive to their customers' needs. So they have you add a one-page questionairre that the order takers will ask whenever a customer calls in an order. Won't cost a thing; after all, the customer is already on the phone.

Production should have better reports of what is going on in sales and distribution. That way, they could plan ahead better if they saw sales going up. So, let's have the production manager spend just a measely 10 minutes a day reviewing reports on each previous day's sales.

And, frankly, we haven't had much of a way to measure how much each worker in the warehouse is actually packing each day, so let's have the workers individually log into the workstation when they want to draw an order, so we know who is doing what.

After about three months of tossing these kinds of ideas into the hopper, what was 10 person-minute paperwork task per sale has become 20 minutes of computer time, with senior personnel breathing down workers' necks and everyone running around trying to control everyone else. Meanwhile, of course, the four guys in the warehouse have worked out a deal where they use one log-in name for the first two hours, the next for the next two hours, etc., because who can be logging in and out of a computer 75 times a day.

Working with the Client

As a designer, it is your job to push back on the client. Explain that a clean, simple design will result in certain efficiencies, but that that "budget" can be used up in no time flat by increasing the tasks performed by everyone on the system.

Do user testing of the simple and complex forms. Speak from your own experience. Quote leading design experts. And put it in writing. Not so you can say, "I told you so," should they go ahead and create a cumbersome system, but so they will remember that lone voice in the woods that tried to save them from themselves, that same voice they will now listen to for second release.

The Designer's Part

Designers are not above augmenting their own horse and buggy. Slash mercilously.

Quite often in software, you end up with a screen and subscreen combination. For example, you might have a screen of incoming widget orders and a subscreen for each order showing details. Finish the screen, finish the subscreen, then take another look at that screen. What can you move from the subscreen to the screen that might allow the workers, most of the time, never to have to look at that subscreen? Perhaps you can put the code numbers for the widget type and quantity on the main screen, so the only reason they would ever go to the subscreen is for special instructions. With a simple flag indicating whether there are special instructions, you have, in most cases, eliminated an entire screen.

This kind of constant reappraisal should continue through the lifetime of the project.

The Engineer's Part

When an engineer thinks in terms of simplifying a design, it usually means simplifying what they have to do to implement the design. This is often contrary to the best interests of the client and user.

For example, when you visited the widget factory (you did visit the widget factory, didn't you?), you noticed that the warehouse people spent a lot of time weighing and looking up postage rates for each package. So you have designed the application to do that computation for the workers. The application has a single screen where weights of every object involved in a completed order, from box to packing list to the widget itself, is listed, along with its weight. On the order screen, the exact postage each order will require is then displayed. Simple and efficient for the client and users, but not for the engineer. In the interest of expediency, the engineer may want to replace all that careful design with a simple type-in box labelled, "Enter postage amount here." Saves a lot of coding, but costs the client a lot of money.

Working with the Engineer

After a while, you will develop a sense of what an engineer is going to complain about and what he or she will cheerfully code. When you have an important issue, don't just kind of slide it into the prototype or design document and expect it will get implemented. Sell it. Sell it to the product manager, sell it to your boss, sell it to the client—more of this in a minute—and sell it to the engineer. Beyond your own exuberant personality, you have your experience in shadowing the workers in the factory, perhaps augmented with videotape. You have written down quotes from the warehouse workers that "this danged old postage thing like to drive us plum crazy."

Be prepared to lose some of these, maybe even a lot of them if the schedule is short. Have your backup plan for first release, and extract a promise (for what it may be worth) that this will be address real soon.

A caution on getting the client too excited: Before promising that you wonderous software will not only facilitate sending out orders, but will cook, clean, and sew, make sure that such capabilities are at least possible and reasonable. Otherwise, getting the client worked up for a feature that is an impossibility could be a disaster.

The rest of this column is, unfortunately, really boring. It is best to sign off now unless you are a software designer, rather than an engineer. It will be really boring for designers, too, but they are required to listen.

Blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah....

Now that we are alone: I always ask for more from the engineers than I'm ever going to get. In my experience, the engineers will cut back on a design no matter what. It is just their nature. If you've asked for just exactly what you absolutely can get by with for release one, you are going to be disappointed. However, if you've asked for what you need plus that vitally important artificial intelligence inference engine for figuring out what the customer wants to order before they've even called, they are likely to let out a sigh of relief when you drop that requirement, and consider themselves lucky that they only have to do everything that's really needed.

Just a Plain Horse and Wagon on Mulberry Street

When the little boy finally breathlessly runs in the house at the end of the story to explode with his tale of magnificant creatures and celebrities all, he can't do it. When Dad inquires as to what he saw, he dutifully reports the absense of lions, tigers, and bears and the presense of nothing "but a plain horse and buggy on Mulberry Street."

Too bad more of our software projects don't revert to such simplicity. Too bad those freqent flyer programs don't either. If they weren't sending us four pounds of useless paper every month, maybe we could fly to Burbank for only 99,000 miles.

Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top