The Art of Computer Science

I got stuck in the Phoenix airport today, along with thousands of other America West Airlines passengers, because the computer that the airline uses to file its flight plans crashed (oops, sorry - failed). For most of the afternoon and evening, every fuelled up, airworthy aeroplane in Phoenix (and other cities, I presume) sat on the ground and went nowhere while otherwise polite-looking people in business suits recreated the village mob scene from Frankenstein, and gate agents tried in vain to make themselves small behind their counters. Through all of this, the only thing I could think was " that poor CIO".

I picture some helpless, hopeless schmoe, technical skills atrophied beyond reclamation by years of forced administrivia, peeking over the shoulders of his DBAs as they desperately pound their keyboards. He paces a little and wrings his hands at the thought of all his hard work - to earn a reputation for delivering innovative solutions and improving user confidence - being pierced by a hail of broken database pointers. Finger pointing, mea culpa presentation slides, action item lists and a lot of other useless thrashing will, no doubt, follow. I imagine his next performance evaluation will read something like: established compelling strategic systems vision; improved decision-making skills and responsiveness; successfully achieved impossible budget and timeline targets; single-handedly alienated 100,000 customers.

In sympathy and solidarity, I decide not to join in with my fellow would-be passengers, opting instead to do that which my brother CIO could only dream of doing at a time like this: removing myself to the Admiral's Club and drinking, heavily.

Eat right, exercise daily, live clean, die anyway.

As I've pointed out in past columns, IS's attempts to please users have always been a sort of isometric exercise: lots of strain that gets you nowhere. Three out of every five CIOs reading this article will be out of their current jobs sometime within the next three years. In many cases that's because those who judge IS's performance, those whose opinions we in IS value most for the influence they have on our careers, our income and, dare I say it, our self-esteem, are too ignorant and too arrogant to be charged with such a critical responsibility.

Easy now . . . down big fella. Let me explain.

We're all irrationally arrogant about most of the miraculous technologies we come into contact with on a daily basis. Take, for example, the telephone. Commercial telephone service has been around for nearly 125 years, and while I'm entirely familiar with how to operate it, I have only a rudimentary idea of how it works (and that idea is probably wrong). In 99,999 of 100,000 times I pick up the receiver to make a call, I get a dial tone. I never think to myself, "Gee, those guys down at the phone company are doing a wonderful job." On the other hand, what I think that .001 per cent of the time I don't get a dial tone is completely unprintable.

Most IS organisations expend between 80 per cent and 85 per cent of their manpower and budgets on "dial tone", the daily support and processing that keeps the business in business. When was the last time one of your users called to register their astonishment and delight about how well their e-mail was working? Punch line: your performance on 85 per cent of what you do this year, what you spend most of your budget on, will be almost entirely overlooked unless it's bad (and that ain't good).

Back at the office, it's performance evaluation time again. Known around here as "the crippler of young managers", it's an annual festival in which dignity and humanity go into palpable decline. In matters as subjective as measuring IT performance, accuracy is not always truth, and performance metrics that ignore outside factors are nearly worthless in assessing quality. What's more, user satisfaction is amazingly blind to degree of difficulty, architectures and strategy. Writing appraisals is difficult to the point of impossible, even for people who understand what constitutes successful performance. So why is that?

An author friend of mine once told me that the reason novelists and most other artists seem insecure all the time is because success in artistic pursuits is so hard to define. Well, guess what? In spite of the lab coats of earlier days, mysterious acronyms and legions of propeller-heads with bad attitudes and even worse social skills, IT is not a science, it's an art. The inarguable fact that there are as many different ways to design and code a program as there are programmers, that there are a million right ways to write an application and one best way yet to be defined, means that it will always be an art, an exercise in making something out of nothing. In fact, it's not just an art, it's performance art, a blending of the softer sciences of marketing, psychology, ergonomics, graphical design and architecture with the harder stuff of bandwidth, clock speeds and seek times all wrapped up in a 30-minute presentation sent begging for budget.

This notion of IT as art form may be one of the least understood yet most vitally important concepts we can share with the bean counters as we go about the ever more challenging job of delivering innovative and competitive solutions, recruiting and retaining creative, productive teams, and fighting to stay in our jobs long enough to have a meaningful impact.

Over the years, we've tried dozens of the several hundred half-baked schemes that have appeared in this and other magazines, journals and textbooks about measuring IT performance when instead I should have been putting them through the shredder and using them to line the bottom of my kid's hamster cage. That the creative process could be measured, studied and somehow enhanced by converting it to numbers is so silly, I'm embarrassed to admit we even tried.

Now it would be wrong (not to mention pointless) to argue that we should be given a pass on evaluations. But it's time to come to grips with the fact that if we always knew what we were doing, always knew how long it would take and what it would cost, it wouldn't be IT, it would be . . . accounting! The way you get meaningful things done in IT is to embark on a process in which you move in a given direction, find yourself at a dead end, back out shaking your head with frustration or disgust, puzzle out why that particular path was wrong and start off again. With every wrong turn, you figure out more, so that every process is an education. The benefit of false starts and ideas that don't pay off is that going through the process of discovery often alerts us to unexpected new directions.

As they say, "Victory goes to the player who makes the next-to-last mistake".

The need for risk taking has never been greater as we struggle to compete on a truly global basis. Yet in most businesses, there's never been much patience for mistakes. As things get more demanding, that impatience is turning inexorably to contempt.

Always willing to try anything, no matter how desperate, we've recently kicked off a comprehensive program of educating my boss, assorted members of senior management (with the exception of our head of HR, whom we've locked in a closet with our scariest XML programmer) and some of my peers in the fine points of assessing our group's challenges and opportunities. We started by making a list of all our hot spots (user acceptance tests, new application implementations, month-end batch runs, the help desk during a Windows 2000 rollout), then doing everything we could to shanghai them into experiencing these efforts firsthand. If things go well, we will begin to change the way IT performance and value are measured. It will also communicate to those doing the work that management cares enough about what they're doing to take the time to understand how it's done.

Wish us luck.

Anonymous has been a CIO at household name companies in various industries for over 12 years. He welcomes mail from artists of all types at

Copyright © 2000 IDG Communications, Inc.

6 digital transformation success stories