All Posts in Technology

|In: Office Politics|Last Updated:

I love golf.

I wandered through a golf show a few weeks ago, looking at gadgets, daydreaming of long, straight drives, and pondering the game as a metaphor for managing IS (not for the first time, either — see my July 8, 1996, column on the subject).

The obsession so many of us have with long tee shots is a good example. Just as most of us would be better off playing a five iron off the tee and practicing our putting, so many CIOs worry about aligning IS strategy with the company’s goals and vision while ignoring the real big-money issue — poor project execution.

So it was that I visited a booth selling custom woods (actually metals, good persimmon being unavailable these days). The purveyors of these fine clubs had a killer sales pitch: Rather than fix my slice-prone swing, they would sell me clubs that compensate for my deficiencies.

For a significant price, of course.

These clubs provide us with a lovely two-sided metaphor. On the one side we have executives who think nothing of spending a sizable fraction of their annual bonuses on these very same custom golf clubs and a supply of titanium balls, but who cheap out when it comes to providing a reasonable set of tools for IS. They believe better tools will help their golf games, but not their businesses.

On the other side we have IS weenies who are convinced that if they just had better tools, they’d suddenly become the ultimate code warriors, able to create magical applications in periods of time so brief that quantum effects predominate.

Examples of the former are easy to find: Data center managers who lack funds to implement network management, developers whose request for source management software is denied, even project managers who aren’t given basic project management software.

Examples of the latter are just as readily found: A friend of mine bought a PC-based Cobol compiler a few years back expecting to develop and unit test mainframe applications on it. A few minor problems cropped up after the money was spent: The systems it was purchased to support ran on top of a proprietary transaction manager and used a proprietary data compression system, neither of which would run on anything other than an MVS mainframe. Oops.

Then there are the fifty-buck tools that solve five-buck problems. In the early days of Unicenter, for example, Computer Associates boasted of its ability to stop batch jobs if available storage filled up, roll off some files to tape, restart the job, and restore the files at the end of the process. The sole design flaw: For the price of the software, you could have bought enough scratch storage to run any batch job you could imagine. Sometimes, brute force can be more appealing than elegance.

Business executives often complain about our buying technology for technology’s sake. The complaints are, for the most part, groundless. The applications IS deploys and manages invariably have a business purpose.

Except for tools, that is. Let’s face it: A lot of us have a yen for the latest and greatest software tools, just like some stereotypical husband with a workshop who wants a table saw or drill press.

How to make sense of requests for expensive tools? The answer is to eschew (gesundheit!) the use of broad principles. They won’t help. The only way you get a handle on this issue is to figure out your core processes first. These usually are (in order of importance): data center operations; applications maintenance; end-user support; system selection, customization, and integration; software testing; and application development. Understand your processes first and you’ll quickly understand which tools you need and which ones may be wonderful, but just don’t fit.

Oh yeah, just one more thing: While you’re busily giving your developers killer workstations with dual overhead cams, fuel injection, and turbochargers, also give them Pentium 133s with 32 MB of RAM to test their works of art. The P-133 is an important developer’s tool.

You’ll be amazed at how much having to use one will improve a typical developer’s code.

Comments

|In: Industry Commentary|Last Updated:

According to published reports, Internet Explorer 5.0 will occupy about 50 megabytes of your hard drive.

Now I’m a broad-minded soul, and a firm believer in letting every single adult American make his or her own trip to perdition in his or her own fashion. If Microsoft wants to ship a 50 megabyte browser, bless its heart. If you want to invest a dollar’s worth of hard drive to install it, bless your heart.

And if Microsoft wants to keep on calling a product it packages and ships as a discrete entity for several OS platforms an integral part of the operation system … well, that’s what we have the Department of Justice for, I guess.

Calling it an integral part of the operating system is an interesting enough claim. I enjoy the folks who call it a “thin client” even more, since it isn’t thin and isn’t really a client, either, merely a platform on which the client software can execute.

Blessed with complete ignorance of all facts, I’m confident Microsoft could have provided identical functionality in 25 megabytes had it established compactness and performance as design goals. The code is almost certainly bloated.

But, as Arlo Guthrie once said in a different context, that isn’t what I’m here to talk to you about today.

I’m here to talk about the consumers who will complain about the bloated feature set of the product, proclaiming with great pride that they only use 10% of the features anyway. The inference they’ll want the rest of us to draw is that Microsoft should remove the other 90% of the product.

Bragging that you fail to take advantage of 90% of what a product has to offer ranks right up there with bragging about not knowing how to balance your checkbook — it’s one of the reasons I’ve suggested organizing National Boycott Stupidity Day in previous columns.

So here’s a simple suggestion to all of you who are happy in your 10% mastery of the basic tools with which you perform much of your daily work: LEARN MORE FEATURES!!!

General office software contains lots of features that can make all of us more effective at what we do. When you’re using the computer, any time you find yourself doing the identical thing more than once or getting things out of whack when you make a revision, you’re probably ignoring a useful feature that would do it for you. You may manually number a list, manually retype the name of a section heading when you refer to it elsewhere in the text, manually format bulleted lists, use the space bar to line up right-aligned columns of numbers … do you see a trend emerging?

Extend this insight to the training programs you offer. We go about end-user training all wrong. Most IS trainers teach features. To drive the cliché off a cliff, we give our end-users fish instead of a rod, reel, and bait. Think about it. How much time do your trainers spend on exercises designed to make end-users self-sufficient, able to find solutions for themselves? Probably very little — that’s usually an afterthought at the end of the two-day Basics class. Teach them to poke around in the menus and help system, though, and they’ll learn how to do all sorts of great stuff on their own, including how to not call the Help Desk.

Now here’s where it’s going to hurt. The hardest part of learning these great new techniques is knowing they exist, right? Wouldn’t it be great if the computer watched what you do and, recognizing when you could benefit from one of its features, automatically suggested it to you?

I’ve spent more than a year wanting to punch Mr. Paperclip in the kisser. I still think he’s an obnoxious little cuss. Looking at it objectively, though, (ouch!) I’m forced to conclude (groan!) that he and his compatriots are a valuable addition (eeeeyooow!) to Microsoft’s office suite.

So if you only use 10% of a product’s features, don’t brag about it. Ignorance may be bliss, but it isn’t a virtue.

Comments