Humour

The truth about programming

T A Balasubramanian on how almost all programming greatness comes from great borrowing, or outright plagiarism

“Well, great Maestro, now that you have started on the subject, could you be persuaded to share an honest ringside view of the art of programming?”

You, Papyrus Bytewala, CIO of Baffle Corporation, are addressing Brooke Bond, your irrepressible head of software projects. The objective of the present session is to enlighten Danny DeVito, currently your CTO at Baffle, about the devious pathways of the IT labyrinth. Bond, the ever-obliging showman, has, thus far, been turning the spotlight on himself as a noble artist who has somehow blundered into the profession of software programming.

DeVito, the stocky, fun-loving humanoid who is a clone of the Hollywood counterpart of that name, is proving to be an adroit listener and a quick learner. “Yes, indeed, Brooke,” he nods.

“All right gentleman and robot, so be it. Let me start off with some preliminary remarks, Danny,” says Bond, clearing his throat. “If you are into software development in any capacity, you will find almost everything that I am about to say exciting and maybe even thrilling. You will be drawing up project schedules that keep dragging on endlessly. You will be obliged to work with vague ideas that do a heroic job of standing for clear feature descriptions. And most importantly, you will develop a remarkable lack of interest in learning from the past. As you travel around the by-lanes of Baffle, you will meet a variety of humans who will seem to do everything to make sure that the project you are on becomes increasingly complicated, even as the users become increasingly impatient with you. You will meet me, and my team, in my many avatars—the indecisive manager, the frustrated designer, and sometimes, the cowboy coder.”

“And, of course, the Maestro, too,” you add, pointedly. “The artist who loses interest in things as soon as the creative work is done, determined to rewrite thousands of lines of code for the sake of incremental elegance.”

“Oh, yes, that too,” Bond sighs.

“What is it that drives a programmer to greatness?” says DeVito, making a fist of his hand and waving.

“Well, Danny, I have to admit that almost all programming greatness comes from great borrowing—or outright plagiarism.”

“What? And this comes from a Maestro?”

“Indeed so, my humanoid,” says Bond, ruefully. “We clone our way to greatness. What you really must aspire to be is a copycat,” says Bond, with a wave of his hand. “Any software engineer worth his salt copies code from anywhere and everywhere he

can find it. It is called reusability, to make it respectable—and it is considered highly professional to create entirely new applications by reusing as much of the old code as you can. Let someone else write the original code and test it till it shines. Your genius lies in knowing where it is, and when and how to use it.”

“He’s right, Danny,” you say. “Coding is all about getting to top speed in generating a bundle of error-free instructions. But Bond has a tendency to—shall we say—dramatize the profession? Rather than ‘copycat’, perhaps ‘efficiency expert’ would be a more appropriate description.”

“Well, Papyrus, an ‘honest ringside view,’ I thought you said … ”

“Of course, Brooke. But without the fanfare and drum rolls.”

“That’s all right, Papyrus,” says DeVito. “I like Brooke’s flourishes. They make good theatre.”

“All right. Efficiency expert is what you want to be,” says Bond. “When you can beg, borrow or steal code, you can crunch time. Consider that if some of your work was actually done by hand, line by line, it would take weeks, perhaps lifetimes, rather than seconds and minutes. I have a major report that I update every month with new data. The database production and report generation takes about two hours of clock-on-the-wall time to produce. We used to joke that it would take 700 secretaries with fast hands at least two weeks to do it. Maybe we should be paid all their salaries as well.”

“I thought you artists were not interested in money?” you say.

“We try not to be,” says Brooke, loftily. “So, while we are imitators, Danny, remember that imitation is the highest form of flattery—at least among humans. If someone copies your work, you should be honored, not offended.”

“Well, look at me, for example” says DeVito, with a chuckle. “A perfect copy of the real DeVito already.”

“But of course, I forgot. So here’s how I work. Whenever I start on new projects, I first look for a similar program either written by me or by someone else. I revise it minimally—only where absolutely necessary. You do not ever have time to write from scratch. I use this rule in all aspects of my projects. If I have to enter data into a database and it exists on word-processed document, I pinch it and fit into the database. Here’s the golden rule—never, never retype information or code unless you must.”

“That seems simple enough,” says DeVito. “So why do most software projects run into hot water?”

“That is where we cranky humans turn out to be the chinks in the armour,” says Bond, solemnly. “A project always becomes a case study about the difficulty of designing software with other people. It is not at all like designing, say, a new car, where real-world constraints—like the laws of physics and the properties of hard materials—come into play. In software, nearly anything is possible, so we have this vast, unconfined space to produce all kinds of results. However, what comes out of that open space—when it is full of geeks—is usually not the thrill of exploring possibilities, but the paralysis of choice.”

“You mean indecisions?” says DeVito. “Leading to compromises?”

“Endless compromises,” says Bond, with a flourish. “We begin with endless meetings discussing what ‘could’ be done, how features ‘might’ work, or what kinds of goodies a user ‘might’ want. And it is always that nebulous term ‘the user’ which we keep rolling around. No project will ever waste much time thinking about exactly who will use the product or, under what circumstances—leave alone actually talking to a real user. That is considered sacrilege—a waste of precious time.”

“So the user is usually the last one to get the message?”

“Yes, and what a user gets are error messages,” you say. “Most software designed today has ‘warring geeks inside.’ No wonder software decay is so universal that every piece of software needs an army of developers to keep the rot in check. True for a Web service like Amazon or Google, where programmers deliver upgrades online. Custom business applications, where the programmers work for the software company or the client company. Or a consumer application, where the programmers provide users with a constant stream of patches and upgrades to keep the bugs at bay.”

“Which would not happen with Maestros who create a world of perfect software,” says Bond, looking skyward. “But it certainly keeps a lot of programmers employed. All this software decay is a more natural model for a world in which we do not get perfection, but we do hope for steady improvement.”

“And what do users hope for?”

“Oh, from the user’s perspective, software almost always decays,” says Bond, cheerfully. “It stops doing what they want it to do, or they try to do something it is supposed to do and find that they cannot. The more they use it, the more likely it is to break. Users, after all are cantankerous and unpredictable human beings, always capable of doing things that programmers have never imagined.”