Humour

Dishing out IT failures

T A Balasubramanian on coping with nightmarish projects

Dr Don Jong is a familiar presence in the inner world of IT and its quaint practices, fondly dubbed ‘The Oddfather’ because of the offbeat treatment he usually offers. Back in his office, Dr Jong resumes his irreverent sessions, handing out clouds of questionable wisdom and eccentric advice as he untangles the many loops and twists that keep popping up for Bobo Jitter, the ever-challenged CIO of Bazooka Corporation.

“Ah, you seem lost in thought … so what is it that brings such a furrow to your brow, Bobo?” says Dr Jong, with a twinkle in his eye.

“I have been thinking, Doc. I have so many nightmarish IT projects on hand, and very often, they fail, even though my team and I put all our heads together and do everything to make them work. It just seems to me that it is unfair when nature seems to conspire against me.”

“Oh, so you are special, eh? You think nobody fails in other projects elsewhere?”

“I’m sure they do, Doc. But do they go through the same harrowing experience that I have?”

“Maybe they do. Let me tell you a story that might help. In 1760, the French astronomer Guillaume Legentil planned the beginning of a celestial observation project, for which he had to be in India. He wanted to see a Venusian transit—a rare occasion when the planet Venus passes directly in front of the Sun—and India was the place to see it. The transit occurred in 1761, but Legentil was held back by the Seven Years’ War, and arrived in India too late. Being an optimist, rather than turn around and head home, he decided to wait for the next transit, which was expected on June 3, 1769. Eight years passed. June 2 dawned sunny and cloudless; but on June 3 the sky was overcast. Legentil saw nothing at all. On his way back to France, he survived two shipwrecks. When he arrived in Paris in 1771, he found that he had been given up for dead and his belongings split among his heirs.”

“Oh, that is mind-boggling, Doc.”

“Indeed so. And that is but a random example from one field. Now, from my experience, IT today is an equally stressful occupation, for many reasons. One of the big reasons is that your users work very closely with computing hardware that, in the present world, does not fail too often—or if it does, it can be attended to easily. Now this means high stress for you, because if there are errors, they are probably in the software—and that is something an IT manager or CIO and his teams are required to fix. Then again, you also have this high desire to please others and that tends to push you harder. You put in more hours and take things more seriously then perhaps another group.”

“But we have to be ready for anything, Doc.”

“Sure, you have to be. But if you do have failures along the way, you could learn from them, even though Douglas Adams once observed cynically that “Human beings, who are almost unique [among animals] in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”

“Mr Adams was right, Doc. Maybe it’s just a lack of interest on anyone’s part to review painful or frustrating experiences when time could be spent moving on to the next new thing instead. Or maybe it’s a fear of what I will find, or the fear of being held accountable for it.”

“Ah, but you must get past that block, my boy. As projects are completed or as they get cancelled—and I see so many development projects end this way, with a quick shutting of the door—little is done to learn from what happened. As psychologists, it is our professional duty to help our patients peer back into their pasts. It seems that managers in most organizations rarely reward people for seeking out this kind of knowledge. W hat I would recommend is hindsight and history lessons for you.”

“And how do I find these?”

“As Karl Popper implied, there are only two kinds of theories: those that are wrong and those that are incomplete. If we take away failure, we forget, in arrogance, that our understanding of things is never as complete as we think it is. The trick then is to learn as much as possible from other people’s failures—what is better known as history. Use the nasty experiences of others to shield yourself from the same mistakes. The superficial details of failure might differ dramatically from project to project, but the root causes or team actions that led to them might be entirely transferable—and easily avoidable.”

“I am still hesitant, Doc. Why rake up the old embers?”

“Ah. I see that you are still persuaded to dither by these old clichés. ‘Let sleeping dogs lie. Let bygones be bygones.’ Nonsense! You must shake yourself out of these stultifying aphorisms perpetuated by grandmothers. In Henry Petroski’s book, ‘To Engineer Is Human: The Role of Failure in Successful Design,’ he explains how many breakthroughs in engineering took place as a result of failure. In part, this happens because failures force us to pay attention. They demand that we re-examine assumptions we had forgotten were there. According to Petroski, real knowledge from real failure is the most powerful source of progress we have, provided we have the courage to carefully examine what happened. And you must admit, it is hard to pretend everything is hunky-dory when your prototype has burst into flames.”

“That’s a tall order, Doc. I mean, looking failure in the eye is scary.”

“Indeed it is. All projects are scary—but so what? Now one niggle with history is that it is not always easily relatable to the present. It can be mind-bending when you try to transfer lessons across decades and connect to things that seem so different from how work is done today. But maybe you can connect the dots with interesting kinds of modern project sites—such as food kitchens.”

“Food kitchens?”

“Yes. They can be enlightening places. Perhaps you have been cornered in horrendous situations where it seemed improbable that anyone else in the universe ever managed anything as complex as what you were doing? The moment you see the split-second task management and coordination that occurs in a large, bustling food kitchen, you will forget how difficult your worst project had been. Cooks juggle frying pans with different orders at different states of completion, scrambling between multiple sets of burners in opposite corners of the kitchen, while waiters run in and out, delivering updates of new adjustments and problems from customers. All of this happens in small, cramped rooms, with temperatures well over 90 degrees, with bright fluorescent lights glaring above. No matter how many orders go out every few seconds, new ones come in just as fast. Sometimes orders get sent back, or, much like software projects, require custom and last-minute modifications—no salt on Table 1, more sauce on Table 2—and so on. It is like madcap project management executed in a real-time bomb shelter.”

“Wow, Doc. That’s interesting. How do you know so much about large kitchens?”

“My father was the Head Chef who ran a kitchen for the Hilton Paris. It was chaotic, but it was like a culinary project management site. You should see the number of failures he managed to convert into great new experimental dishes every day!”