All Posts in Industry Commentary

|In: Industry Commentary|Last Updated:

Stupidity comes in two flavors.

Sometimes, we just don’t think. We forget anniversaries, miss our freeway exits, sleep past our bus-stop, call one of our kids by the dog’s name. Stupid.

It’s stupidity, but it’s OK, for two reasons. First, we’re all bozos on this particular bus. Second, we’re stupid because the smart thought never came near us to be chosen instead. We were sleeping with our eyes wide open.

Then there’s Microsoft Outlook. Why, oh why would you design a system that replicates all server data on my local hard drive, then uses expensive, slow, network bandwidth for every operation when the free, fast connection between my hard drive and the CPU is there for the asking? I could, of course, use the “Work Remote” option, only then Outlook can’t use the network link, only the modem connection. This is ActiveStupidity.

(Disclaimer: I’m picking on Outlook because I use it. For all I know, Notes and GroupWise are just as bad.)

Then there’s IS’s current love-affair with browser-based applications. I use one on a regular basis, through a 128Kbps WAN connection, and what would be a 1-minute job with a client/server GUI instead takes 10 minutes of mostly thumb-twiddling.

IS has fallen in love with fat network architectures. Fully buzzword-compliant software companies call browser-based user interfaces “thin-client” applications, but they aren’t, because a) browsers aren’t thin, and b) the thinness of the client doesn’t depend on where it executes, only on how well the business logic has been isolated from the presentation. I’d like everyone who misuses the term “thin client” to write this on the blackboard 50 times: “A ‘client’ is a software process that makes a request of another software process. A ‘server’ is a software process that receives a request from a client and satisfies it.”

Architectures that ignore the capabilities built into intelligent desktops in favor of servers at the wrong end of a WAN link may or may not be thin-client architectures. They are fat-network architectures every time, though, because they require faster (read “more expensive”) WAN connections and bigger (read “more expensive”) servers to achieve a user experience that’s a fraction as satisfying as the one you can achieve through a local GUI.

IS has fallen in love with fat network architectures because they’re easier to manage than n-tier client/server architectures. Never mind that an increasing fraction of the workforce is mobile, where bandwidth is limited to modem speeds and the laptop is tethered to a hotel telephone. Our Total Cost of Ownership has gone down! Break out the champagne.

A correspondent from a prominent software supplier noted for its advocacy of fat-network systems took me to task a while back for missing their elegant beauty. His company’s system, for example, downloads Java applications that supplement the browser’s limited functionality in tiny little 100KB chunks. “It runs over a 56Kbps modem!” he enthused.

Let’s see. Factoring in protocol overhead, a 56Kbps link delivers a little over 5.6KBps. That means each of those tiny little Java applications will download in only … 17 seconds. There’s a satisfying response time. Never mind the sub-second response time you’d get with software installed on the hard drive. To keep the delay under 2 seconds you need to connect at full T-1 speeds. Take a look at your WAN. How many 128Kbps links would you need to upgrade?

I don’t get it. Pundits keep writing about the ultimate in thin-clientness: Keeping all their private files on nice, public servers so they can access them anywhere through public terminals … along with every cyber-vandal and cracker on the Internet. That’s much better. Of course, they’d still have to haul their suitcases and briefcases around, but it would easily eliminate 10 percent of the total luggage weight.

Given a choice, I’d rather lug my laptop and rent clothes from the hotel. No more lost luggage, no more suitcases to drag through the airport … it would be a slice o’ heaven.

I could really get behind a “thin-luggage architecture.”

Comments

|In: Industry Commentary|Last Updated:

If, except for the concussions and bruises, you’d enjoy an old fashioned bar brawl, come on by the forums on InfoWorld Electric. They’re great places to test your thoughts in the marketplace of ideas.

They’re lousy places to learn diplomacy, but great places to float a concept.

A recent column and forum addressed the frequent complaint that “I only need 10 percent of the features. The rest are useless frills.” It suggested that instead of complaining about feature bloat, you should learn more features, because there’s a lot of useful stuff in there. (Code bloat, of course is a different matter entirely.)

Somewhere in the lively discussion that followed, a question occurred to me: The people who claim they only use 10 percent of the features don’t know the features they don’t use. How do they know they’re only using 10 percent? Since you don’t know what you don’t know, you only know the numerator, not the divisor.

No matter: If software follows the everyday laws of probability, you’ll use 10 percent of the features 90 percent of the time. The two questions are: (1) What’s your personal point of diminishing returns? and (2) If you don’t use a feature, does its presence constitute feature bloat?

And then a colleague of mine asked one of those questions that make you lose interest in the original issue: “Never mind the software, Bob,” he asked me. “Do a lot of managers only make use of 10 percent of the capabilities of the people who work for them?”

Now there’s a question to conjure with. Can’t you just hear the feature-bloat arguments extended to employees?

“I only asked you to document the network, Jill,” a systems manager might say. “Your recommendations on how we can optimize it wasted space on the server and made me spend more time reading your report.”

The answer to my colleague’s question, then, is a resounding, “Yes, and ain’t it a shame?”

We’ve come a long way from the check-your-brains-at-the-door days, but nowhere near far enough. Most of us do understand the benefits of empowering employees, pushing decisions out to the people who do the day-to-day work. We do require thinking rather than forbidding it like we used to. That’s good.

It’s good, but it isn’t good enough, because when you’re in a leadership role you don’t get the most out of your employees by keeping them in their comfort zones.

Here’s an exercise for you. For each of your direct reports, list three responsibilities you think they’re capable of that aren’t part of their current job but are part of your department’s charter. Now ask your direct reports to do the same for themselves, and compare their thoughts to your own. Your list is a set of menu options the employee has never clicked on; their list describes features and capabilities you’ve never tried to use.

Every employee should have stretch assignments – responsibilities that require unproven skills and abilities – on a regular basis. In the list you and your employees have just created are the opportunities. Stretch assignments are good for both of you. For the employee, a stretch assignment is the fuel that propels career growth. For you, stretch assignments expand the capabilities of your department.

The rules for stretch assignments are simple. First, they have to be important, but not vital. By definition, they’re riskier than other assignments, so while success has to generate real benefit, failure shouldn’t result in serious harm.

Second, don’t expect perfection. People rarely do things perfectly on the first try. Sometimes, a feature is buggy in the first release but gets better in the next one. Employees should se stretch assignments as opportunities, not as potential career busters.

Third and last, you must offer enough support that the employee can succeed, but not so much that you eliminate the risk of failure. When employees can’t fail … when they don’t make real decisions, deal with real uncertainty along the way, and make the correct choices when doing so … they can’t succeed, because without the possibility of failure there is no success, only completion.

Comments