When I lived in Washington DC I wanted to write a book about a Russian invasion. Troops and tanks surround the city, then enter to take the capital.

Eight weeks later, exhausted, out of fuel, low on rations and hopelessly lost, the Russians surrender.

The Washington street system is ridiculously complicated, even if you ignore the potential confusion between I Street and Eye Street. There are those who think PCs also are far too complicated.

I don’t.

A few months back I wrote about one reason PCs seem hard to use: no matter how simple each function may be, PCs provide so much capability that just keeping track of all the different easy things you can do is tough. People gripe about this when they talk about “feature bloat” – a ridiculous complaint, equivalent to griping about the menu at a Chinese restaurant because all the choices make it hard to decide what to eat.

PCs seem complicated for a second, more subtle reason: they seem complicated because they simplify tasks that are intrinsically complex.

Yes, that’s right. The PC’s ability to simplify complex tasks makes them seem hard to use. What’s really going on is that the PC reveals our own lack of knowledge.

I learned this a long time ago training end-users in Lotus 1-2-3, back when DOS was king and the Xerox Star ran the world’s first GUI (but nobody cared). “Here’s how you calculate a percent,” I’d explain. “What’s a percent?” someone in the class would inevitably ask.

So I’d explain percentages, but I knew most of the students left figuring Lotus was just too hard to learn. They were wrong, of course. The software had nothing to do with their ignorance of basic arithmetic.

This problem recurs in every software category. Electronic spreadsheets make mathematical modeling relatively easy. They don’t, however, make mathematics easy – mathematics and mathematical modeling are intrinsically hard.

Word processors make the mechanics of document creation and formatting pretty simple. They don’t, however, simplify the fundamental process of organizing thoughts and translating them into coherent explanations.

End-user databases highlight this even more: Access, Paradox and Approach all make it easy to define databases, create entry screens, and format reports. They don’t, however, teach you the business problem you’re trying to solve, redesign processes to take advantage of automation, or create third-normal-form data designs.

Don’t think of this as an overwhelming problem that makes end-user education impossible. Think of it as your new design specification for your PC training program.

Create two parallel curricula. One, for end-users who know the subject, teaches the mechanics of the software. The other teaches business skills using the PC.

Here’s your new course list:

  • Basic Business Writing using MS Word: Memos and Letters
  • Advanced Business Writing using MS Word: Reports and White Papers
  • Business Math using Quattro Pro: The Basics
  • Business Math using Quattro Pro: Introduction to Mathematical Modeling
  • Introduction to Data Design using Paradox
  • Business Automation using Paradox
  • Creating Efficient Work Processes using Lotus Notes
  • …Get the idea?

Don’t, by the way, fall into the “snooty waitron” trap (“Sorry, that’s not my table.”) Far too many companies artificially divide employee knowledge into technical skills and business skills, with separate training organizations for each. You only have two choices: either help end-users succeed, or teach irrelevant material.

Listen closely when end-users have trouble using their computers. If they aren’t complaining about an installation problem (not an ease-of-use issue at all) you’ll find every complaint falls into one of two categories. Your end-users may be complaining because they can’t find a feature, or don’t know to look for the feature in the first place. Emphasize how to find features, and create “cheat sheets” built around common end-user tasks rather than the software menus.

Or their task may be intrinsically complex – a tax-adjusted return-on-investment analysis, for example. Build a subject-based curriculum like the one just outlined.

Build your training programs to solve these problems and you’re far more likely to deliver real value.

Back when the earth was young and I made a living writing Fortran, SAS, and Cobol code (in order of personal preference) I learned a technique called “pseudo-conversational” coding, well-adapted to the IDMS-DC programming environment at my place of employment.

Pseudo-conversational code inverts the intuitive sequence of events. The final event of a pseudo-conversational program displays a screen; then the program terminates. No program is running while the user interacts with the 327x display terminal.

When the user presses the Enter key, that initiates execution of a new program whose first step is to read the screen contents, process them, present a new screen, and terminate. Hidden codes in each output screen determine which module to execute next; more hidden codes are used for parameter passing. Pseudo-conversational coding is handy because the CPU doesn’t waste any cycles while those pesky end-users decide what to input.

It also should sound familiar – the World Wide Web works the same way. So except for minor details like the difference between designing highly graphical pages and green-on-black character-mode screens, old mainframe jockeys should have no trouble adapting to the modern era.

Since I’m in a retrospective mood, let’s go to the mailbag and follow up on two previous columns, starting with the one that got some of those old mainframe jockeys so upset: my contention that the mainframe is dead. If you’re tuning in for the first time, I claimed that IBM’s new CMOS “mainframes” are really big servers to which IBM has ported the MVS operating system. (See “The mainframe is still dead – but your career doesn’t have to be,” May 12, page 63.)

“IBM could have announced that it had ported MVS to its midrange computers instead. It’s all in how you look at it, of course, and if it makes Big Blue happy to call its new super server a teeny-weeny mainframe, well, so be it,” I also said.

For all the readers who took issue with my assertion, hey, it’s OK if you call it a teeny-weeny mainframe too. In my own satirical way, I was trying to point out that the term “mainframe” has lost all utility and should be retired. I hereby propose a replacement term: “batch server.” Whether the box runs MVS, VMS, or Unix doesn’t matter. If it’s optimized for batch processing – that is, it delivers high throughput, drives very fast printers and mass storage, and ships with software tools for job scheduling, distribution management, and stuff like that – then it’s a batch server.

Speaking of missing the point, the same article included this: “… very little has boded well for OS/2 since IBM took it over from Microsoft.” Many readers mistook this cheap shot at IBM for a cheap shot at OS/2. Complain about my cheap shots all you want, but double-check to make sure it really was your ox I gored and not someone else’s. OK?

Funny thing about the mainframe column. The forum on InfoWorld Electric (http://www.infoworld.com/printlinks/) was pretty lively and ran about 10:1 against my position, often in highly colorful terms. My e-mail ran about 10:1 in favor of my position and offered sympathy regarding the flaming forum. Two samples of reader opinion, both biased.

Bad samples lead to bad conclusions, which brings to mind my recent column bemoaning the lack of error bars and mentioning other flaws in most business presentations of statistics. (See “Pie charts and bar charts may bring comfort, but wisdom is a another matter,” May 5, page 74.) The article made the points that a lot of “information” is simply worthless nonsense paraded as knowledge and that some executives apparently prefer misinformation to ignorance. An important subject, I thought, but not one to arouse passion.

Wrong again. Large numbers of InfoWorld readers sent their compliments, war stories, and personal favorite ways of misleading people with graphs and statistics. This problem bugs people big time, as it should. Spread the word.

On the same column, two readers took the time to provide attribution for the quotation that headed the article (“Statistics are used as a drunk uses lampposts – for support, not illumination”). Joel Miller has seen this quote attributed to Peter Grace of W.R. Grace but can’t vouch for it. Bob Forgrave tells us that he ran across it in advertising legend David Ogilvy’s book, On Advertising.