Humour

More cats at work

T A Balasubramanian on how CIOs have learned to live in the midst of a feline zoo

“Well, we do have more mysterious cats to bell here in these job descriptions,” sighs Gulabi Manpowa, the HR Head at Baffle Corporation.

She is addressing you, Papyrus Bytewala, the resident elder hound and CIO of Baffle, presently grappling with your ‘people requirement projections’ and therefore obliged to decode the requests to Ms Manpowa. The eloquently worded brief has been prepared by your incorrigible project team leader, Brooke Bond, a techie too engrossed in his own liberal interpretation of IT staffing needs to bother with the niceties of clarity that might make sense to the average non-technical corporate denizen.

“Brooke says he wants a few Dreamers. This breed, he says, ‘is highly prized by most IT managers and can be a valuable pet in the team. Dreamers are good at weaving the overall structure of the code. They dream of flying objects and love putting their boxes on printable whiteboards. They enjoy solving business problems by abstraction and system analysis, and they relish the chance to turn all those cloudy ideas into code skeletons.’ Explain, please?”

“Ah, yes, we seek Dreamers, Gulabi. Strange as it may sound, much of the work of programming begins in wispy images conjured up by these sleepy-looking creative creatures who delight in working in a medium so tractable—pure thought-stuff that we call objects—which nevertheless exist, move, and work inside machines. However, while a Dreamer often has great ideas, his or her code may be so skimpy or obtuse that no one can pick it up and extend it. Which is why most of the time, the Dreamer’s code may become a single-owner pet—it cannot do tricks for anyone else.”

“In which case, why does Brooke want them?”

“We need the best and the brightest, Gulabi, and sometimes that means we have to take in the eccentricities in order to get the nuggets. Some Dreamers are only interested in getting the code started and then handing it over, bare bones and all, to someone—a lesser cat in the jungle—for completion. It is like master painters who start great works of art and leave the finishing to their apprentices.”

“All right, so be it,” says Gulabi, shaking her head. Then, wistfully, “Papyrus, it would be a lot easier if you could just specify what special education these coders—oops, I mean engineers—should have. I cannot imagine how I would go about hiring a Dreamer, you know.”

“Well, Gulabi, I understand your plight. But you should bear in mind that my software engineers are craftspeople trained to use a refined set of tools to generate a precise product that will work reliably in very specific environments. Like any other craft, computer programming has spawned a body of wisdom, most of which is not doled out conventionally at universities or in certification classes. Cats, by nature, cannot be trained. Most cats learn the so-called tricks of the trade over time, through independent experimentation.”

“You IT guys and your tricks of the trade—this is beyond my horizon,” wheezes Gulabi. “The next set that Brooke wants is called Builders—which, he says will complement the Dreamers. Here he goes: ‘This creature just loves the process and result of writing code. Builders do not always have a master plan, but they are fast and their code is usually free of bugs even in the alpha stage. Much of a Builder’s code originates from intuition and thus they appear to code by the seat of their pants.’ You want people like this too, Papyrus?”

“What can I say? We are all here to fly headlong into the wild blue yonder when we start a project. So we cannot live without these daredevils, Gulabi. A Builder works by gut feel, and generally carries around the master plan in his or her head, so the code flows naturally from this source. Ask a Builder for documentation and he or she will obligingly say that the code is self-documenting. We try to pair a Dreamer up with a Builder, and hope for the best. This is like yin and yang—one makes up for the other’s loopholes. Together, they often crack big projects with great enthusiasm, and that gets the juices going for the entire team.”

“It amazes me how you get your teams to work, Papyrus.  Well, the next creature on Brooke’s list is the Picassos. He says, and I quote, ‘Writing code is as much an art as a science which is why most universities have a monolithic unit called the College of Arts and Sciences. If you wipe out the artistic side of programming, you might lose many Picassos who find great joy and satisfaction in the craft of coding. Picassos love the act of creation—they take business requirements, play with them to make beautiful code scenes, and elegantly paint in user interfaces they consider to be masterpieces. Some Picassos, when working with no visible interface, will create beautiful symmetries of logic that they can admire.’ What do you think, Papyrus?”

“Umm, Brooke does go on and on there, and I suspect that he fancies himself as a Picasso in the making. He has, in the past, created reams of code that he used to display in frames to admiring girlfriends in his living room. However, the downside of being a Picasso is that it means extended coding time and delays in the project, as well as potential minefields.”

“And why is that?”

“Picassos are perfectionists. The tireless Master tries to see how many logic symbols can be packed elegantly in one line of code and still get a correct result. Moreover, any ordinary code that does not reflect artistry very often gets neglected. Picasso does not care about the mediocre stuff that makes the world chug along. Which means that if you rely exclusively on Picasso’s mercurial moods, you have a programming time bomb—parts of which are designed beautifully—waiting to go off under the fingers of your innocent users.”

“And you still want Picassos in the team?”

“Of course we do not actively want these prima donnas. However, they do serve a useful function—since they love showing off, they can often teach others to code with all the craft and care they bring to the job. We take care, however, to have all those beautiful creations tested and double-tested before release. Which, of course, means more delays in the projects.”

“Then, of course, Brooke wants the Mechanics. He says, ‘programming is described as software engineering, but I like to think of most of it as plain and simple mechanical work.’ Quite a switch there, eh?”

“He is right. Mechanics are what we really need in bulk, Gulabi. Mechanically produced software is the opposite of what the stylish Picassos will turn out. It is not a bad thing because in the best sense of the term, mechanical engineering is the humdrum application of science to software problems. You need Mechanics to create those strong bundles of code which make programs work like horses. The only road bump with Mechanics is that they are fixated on hardware. They forget that software should be flexible and easy to reuse. Hardware usually serves one distinct purpose, and you do not always want your software to become stiff and ready for disposal after one use.”

“That’s a mixed bag of cats you are ordering, Papyrus. How on earth do you intend to manage all this?”

“Like I do almost everything else—by walking on a tightrope, balancing the pole. We CIOs have learned to become trapeze artists. Even if it means having to live in the midst of a feline zoo.”