Quite a few years ago one of the Jims reporting to me created an innovation called the “Daily Musing”. Each musing was a tidbit, milder than but akin to those that grace the top of this column, that appeared on the user’s screen while logging in.

The Daily Musing became quite popular, and employees inundated Jim with submissions. Having your musing appear became something of a status symbol.

One submission (from the Curmudgeon Calendar) read, “Happiness is seeing your Mother-in-law’s picture on a milk carton.” You can see what’s coming. An employee complained, calling it a “clear case of gender-bashing.”

We tried to save the feature, but after reviewing the situation with Human Resources we concluded it was hopeless. We worked through several examples and found that only by extracting every last bit of wit could we make the musings safe for employee consumption. Even making it optional wouldn’t help.

(I happened to walk past the complainer’s cubicle not too long afterward. In the cubicle next to hers I saw a sign that said, “Grow your own dope – plant men.” Too bad about that gender-bashing thing.)

Another example of Human Resources killing a morale booster? No, HR was just the messenger. Our HR folks did their best to help us preserve our “Daily Musings”.

Two recent columns have painted the HR industry in a less than favorable light, and reader response has been awesome in its volume and passion. Only a handful of readers spotted a key point: HR doesn’t become a bureaucracy unless line managers willingly abdicate responsibility. Many look to HR for protection when they make mistakes. Many more give HR the dirty jobs they don’t want — like giving employees bad news.

Yes, all too often, HR departments act in ways that deserve criticism, and there’s no point in pretending otherwise. Please notice that I said, “All too often,” not “Always” or “Usually”. Human Resources, like all internal support organizations, walks the fine line separating administration from bureaucracy (for a wonderful discussion of this subject, get hold of Larry Miller’s Barbarians to Bureaucrats). It also has something less than a free hand. HR helps implement the desired corporate culture — it doesn’t formulate it.

IS managers rarely offer compliments to HR. I think I know the reason: IS walks the same fine line, and comes over to the dark side easily as often. Yes, young Skywalker, when you take off Darth Vader’s helmet you just may find your own face inside.

Take an hour or so to look in the mirror. How long are your lists of “company standards” and “IS policies”. How flexible are you in interpreting them?

How much effort do you expend explaining your standards and policies? Do you explain them only when you issue them or often and in terms that demonstrate their value to the company and end-users?

When you find an end-user has violated one of your policies, do you just enforce the policy or do you take time to explain why it exists and is important? And when you’re done explaining (or better, before you start) do you ask why the employee violated the policy in the first place?

Have you ever said the equivalent of, “We won’t do it for you, we won’t give you the tools to do it yourself, and we won’t let you buy the tools either, because after you build it you may ask us to take over support”?

Did you write the e-mail policy that says the system can only be used for business purposes and that violations will be noted in the employee’s records?

The key questions to answer to find out if you’ve joined the Borg collective: Do a lot of your policies, procedures and standards exist for your own convenience? Borg! Is your first instinct when faced with an issue to draft another one and add it to the book? Borg again! Have you ever reviewed your policies and procedures to figure out which ones you can eliminate? Congratulations! You’re still human.

Human Resources has to deal with executive style, employment law, and union contracts. Accounting has to conform to both Generally Accepted Accounting Principles and the tax code.

What’s your excuse?

I spent five long years studying the behavior of electric fish in graduate school before becoming a professional programmer in the world of commerce. Not a day of my fish research was wasted – I’ve reused nearly everything I learned in graduate school in my business career.

You’re probably expecting a segue from reuse to object technology. Nope. Not this week. We’re going to apply part of the philosophy of science to your day-to-day business decision-making.

My colleagues and I had many a fine discussion about which theories had scientific value and which ones provided bull-fodder when mixed with a few mugs o’ brew. The short version: only theories that have both explanatory and predictive power are scientifically useful, because theories that explain but don’t predict can’t be tested.

Businesses deal with theories all the time. To their misfortune, businesses have only one way to test a theory: Try it and see what happens. Sadly, the results still don’t tell us much. Businesses want to make money, not test theories, so they don’t apply the kinds of experimental and statistical controls that lead to confidence in the results. One perfectly valid business theory may be associated with marketplace failure (perhaps due to poor execution) while another – a really stupid idea – ends up looking brilliant because the company that followed it did enough other things right to thrive.

While business theories are rarely as certain as, say, the laws of thermodynamics, they’re often good enough to be worth using – if they’re useful and not just interesting. Good business theories must be useful, and that means they have to provide guidance when making decisions.

And that takes us to last week’s column on the difference between client/server computing and distributed processing. “Client/server”, you’ll recall, refers to a software partitioning model that separates applications into independent communicating modules. The test of client/server isn’t where the modules execute, it’s their separation and independence.

Distributed processing is a hardware and network architecture in which multiple, physically independent computers cooperate to accomplish a processing task.

You can certainly implement client/server computing on a distributed architecture – they go together naturally – but they’re not the same thing.

I could almost hear some readers saying, “Oh, come on. That’s just semantics,” while writing the column, but the distinction matters. In other words (we’re there!) we’re dealing with a useful business theory.

One of our teams used it recently while helping a client sort through some product claims. One vendor touted its “paper-thin client” – it uses X-Windows on the desktop – as one of its desirable design features. A thin-client design was just what we were looking for, because we wanted to reuse a lot of the core system business and integration logic in new front-end applications.

Looking at the product more closely we discovered something wonderful. The vendor hadn’t implemented a thin client at all. It had built a fat client that mixed presentation and business processing together, but executed it on the server. Their system used paper-thin desktops, not paper-thin clients.

Thin desktops may be just what you’re looking for. Thin desktops reduce the cost of system management (fewer desktop software installations) and can give you highly portable applications. They come at a price though – an impoverished interface and a much higher processor load on the server, to name two.

We weren’t looking for thin desktops. We wanted to reuse a lot of the application logic built into the system, and that meant disqualifying this particular product.

Take a minute to think about some of the claims you’ve read about the network computer (NC). Ever hear someone refer to it as a thin-client architecture? I have, but it isn’t any kind of client architecture. It’s a distributed computing architecture. Whether the applications you run on an NC use thin clients, fat clients, or just terminal emulators depends on how you or the vendor partition the application logic and where you execute the various modules that make up the application.

Think the distinction between distributed processing and client/server computing is “just a theory” or “just semantics”? Think again: it’s central to your technical architecture.