All Posts in Technology

|In: Industry Commentary|Last Updated:

My kids (Kimberly and Erin, to properly identify the guilty parties) regularly sponsor an event they call Drive Dad Nuts Night (D2N2).

All kids do things that drive their parents nuts, of course. It’s their cunning revenge for all the things parents do to drive them crazy. My kids are no different, except that as a perfect parent I give them no cause for D2N2.

High on the list of things that drive Dad nuts is the need to repeat the same information over and over before it penetrates their consciousness. It’s my own fault: I’ve taken an important principle of communications theory – injecting redundancy into a signal so it can penetrate noise – and inappropriately replaced it with the data design principle of eliminating redundant data.

Repetition is important in a noisy channel, and few channels are noisier than print communications, what with advertisements, news articles, and other columns standing between you and my opinions. Which, of course, is my excuse for revisiting an earlier topic this week.

The subject is the difference between the idea of client/server computing — a software design concept — and distributed computing, which deals with hardware issues.

Most writers in the trade press don’t seem to worry about this distinction — even in these hallowed pages. And it isn’t a mere semantic nicety. It gets to the heart of every current hot issue in computing. If you get it wrong you’ll make bad decisions about important, practical, day-to-day problems.

Here’s a quick recap for readers who missed my previous columns on the subject. (See “Only circular reasoning proves C/S systems cost less than mainframes,” Feb. 10, page 62.) “Client/server” refers to software designs that partition applications into two or more independent, communicating modules. Modern designs use at least three partitions: a presentation module that handles all user-interface logic, a business logic module that takes care of data processing and integration issues, and a DBMS that handles all details of data management. Three-partition designs — three-tier architectures — are themselves giving way to n-tier layered architectures as software designers gain experience and design theory gains subtlety.

Not only doesn’t a client/server architecture care about where each partition executes, but the best architectures make each partition portable. Which is why the “mainframe-vs.-client/server” controversy is so nonsensical: It’s easier to create n-tier client/server applications in which every partition executes on the mainframe than it is to build them with each partition executing on a separate piece of hardware.

“Distributed computing,” in contrast, refers to hardware designs that facilitate spreading the computing load over multiple communicating computers. Client/server applications are easier to distribute, of course, than software monoliths, but it’s certainly as possible (although not yet commercially viable) to deploy symmetrical multiprocessing across a LAN as it is to deploy it across a system bus.

Think about your business goals for client/server and distributed architectures. Lots of us, blurring these two concepts, expected client/server systems to cost less than mainframes by running on cheaper hardware. Since client/server doesn’t speak to hardware this isn’t a meaningful goal. The point of client/server architectures is to reduce costs by maximizing code reuse.

It’s distributed computing that ought to reduce hardware costs, and it can, if a distributed design fits your application load better than the alternatives.

Let’s apply the distinction between client/server computing and distributed architectures to Web-based systems. You often hear people describe the browser as a “paper-thin client” when it isn’t a client at all. The supposed client’s thinness is described as a “good thing.” Why? It’s portable! And you don’t have messy software installations to perform on the desktop! And it’s … well, it’s thin!

Regarding portability: 3×78 emulators are portable, too (and thin). So what? And software installations don’t have to be messy if you’re careful. Thinness? You have processing power to burn on the desktop.

Browsers are incomplete clients. They do format the screen and accept keystrokes, but except for drop-down lists they can’t handle other aspects of presentation logic, such as screen sequencing and data validation.

And that’s why Web-based forms are so slow and irritating to use. You’re waiting for a host computer to notice you, process a whole screenful of input, and send a response.

We ought to know better.

Comments

|In: Industry Commentary|Last Updated:

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.

Comments