Do better PC’s and GUI applications make people more productive? This is an intriguing question. In the early days (Shish – we’re talking only 3 or 4 years ago!) there were a number of published studies that suggested the Wintel PC phenomena was a big step backward. These studies documented a substantial loss of productivity in clerical and office workers caused by what was described as the futz factor -- the constant changing of the wallpaper, desktop color schemes, screen savers, folder names and locations, illicit games, etc. that seemed to occupy 4 to 6+ hours a week of most peoples PC screen time. That plus the constant retraining curves of newer and "better" (by whose standards I wonder?) office applications, the rampant hardware incompatibilities, and the interminable delays at the overworked help desks was said to make many office workers 10 to 20 percent less productive than before the introduction of desktop computers

Even today after the impact of many of the above problems have been dramatically reduced, most of us in the MultiValue community still believe that the majority of our users would be much more productive with dumb terminals for straight character data entry. We don’t have to worry about various viruses hitching a ride into the network on 3.5 inch floppies (or corporate and customer information hitching a ride out!). No Myst or Doom to clog the machines or peoples minds. No terminal envy, no constant upgrades, no compatibility problems, etc.

Well then, why would anyone in their right minds buy PCs instead of terminals for data processing? Bob Lewis wrote a column about this in the 3/31/97 InfoWorld magazine. In effect, he says this is a trick question because the answer lies in the difference between being productive and being effective. He used the example of the executive that used to be able to have a letter dictated, corrected and out the door in 5 or 10 minutes of his(/her) time. Now that executive typically spends 30 minutes or more typing the letter into a word processor or E-mail system for direct transmission to the staff. Bob says that while the executive seems less productive because he spent more time on the letter, he is more effective because the communication will get to the recipients faster and besides, we save on secretary time that can now be put to better use.

I think Bob’s distinction between productivity and effectiveness is a very interesting point, but his example is certainly out of whack. In most shops E-mail between offices may save postal transit time, but the volume of useless trash that I have to wade through every day is an outrageous drain on my effectiveness and productivity. On the other hand, I guess that if executives take longer to compose the memos. there will be fewer total memos. Maybe there is a useful productivity improvement lurking in this second order effect? Perhaps that’s the real goal of the PC and Microsoft – to keep our management teams busy so the rest of us can get some work done? Well – it makes a good ‘B’ movie sci-fi plot anyway.

Lets get serious for a moment. Of course there are classes of knowledge workers for whom the PC raises their effectiveness dramatically. To ask these people to use dumb terminals would virtually prevent them from doing their jobs. There are also classes of untrained users where the presumed shorter GUI learning curve is clearly effective, especially if you have to provide computer access to the general public (such as non-employees). But there are also vast classes of users where dumb terminals are absolutely the right and productive input medium. The point is we must be thinking about specific business goals in order to find the correct solutions. When productivity and effectiveness get confused, both typically suffer.

Remember some of the early attempts to measure and motivate programmer productivity? These efforts were bound to fail because programming is not a repeatable process. You’ve undoubtedly heard the story about the company that decided to pay its programmers by the lines of code produced? They thought it would motivate the programmers to increase productivity (read complete projects faster). Instead they found they ended up paying programmers to code faster – not the same thing at all. In fact, the MIS group’s effectiveness obviously took a nose-dive as programming design, unit testing, and documentation were all short changed in the rush to turn out lines of code.

How many of you have struggled to improve the performance of a systems process (its productivity) only to find later you should have concentrated on its workflow issues (its effectiveness)? In the consulting and systems design arena, I constantly visit shops that are heavily focused on improving productivity. Please they say, make this report run faster. Now I’m an accomplished consultant and I’m really good at making things run faster, but I’m also pretty good at asking seemingly silly questions like "what is this report used for"? The number of obsolete files, redundant or incorrect reports, unowned processes, and bad design turned up by this simple question is utterly amazing. By backing up a step or two I can often combine or eliminate several reports, several updates, or several whole systems to produce more effective MIS solutions that also happen to be more productive.

Passing a large file twice to get a detail and a summary report happens all the time. Passing a file 10 times (or 50 times!) to get reports broken down by salesman (or office, division, product line, etc.) instead of sorting on that attribute and running an extra control break is distressingly common. These are obviously, at least after the fact, non-effective ways of tackling these problems. It would be equally silly to ask a speed typist to use a mouse to enter ASCII data. But even well designed GUI’s often force users to use the mouse. My current pet peeve is an internet application I use several times a week where I need to enter a single field and send it to the server. It would be quite natural to enter the field and type a return but the application forces me to go to the mouse, position it over a the only button on the form and click. Every time I have to use this program, my dislike for GUI’s and GUI designers is very effectively increased, but my productivity is lowered. GUI based products are not automatically better -- bad GUI design can be at least as bad as bad dumb terminal screen design.

The Dilbert cartoon draws much of its humor from this confusion between productivity and effectiveness in very real life situations. In this time of rapidly changing technology, I urge all of you to become more consciously aware of the difference between learning to become more effective and struggling to become more productive. Both have their proper place in your shop, but if you’re not sure which is which, your probably suffering from a significant lack of both. Ask yourself if Dilbert would feel at home in your office.