Humour

Of missions and bugs

T A Balasubramanian on smart programmers who have to write for nasty little bugs

“Every software project is like a mission to Mars launched by a bunch of unruly kids. Everyone has had a hand in it—the marketing people, the prospective customers, the existing users, the engineers themselves, the product managers—everybody’s pulling in some direction. Nobody’s sure about where they are aiming, or when they might get there,” says Brooke Bond, your ebullient project head. 

You, Papyrus Bytewala, CIO of Baffle Corporation, have been moderating a session between your CTO, Danny DeVito, the biped humanoid, and Bond, who has been taking the long route to present a panoramic and exhausting tour of what it takes to build software. 

“So getting a bunch of programmers together is like a shot in the dark?” says Danny DeVito, the biped humanoid, with a grin.  

“You could say that, yes,” says Bond, solemnly. “It is the nature of code to be taxing to create and manage, and difficult to keep clean. So people who spend all their time with a compiler and a debugger have to be emotionally suited for that role. They will not last long if they do not find it satisfying to do the things they do.”  

“Which is to dream up code and go after the nasty bugs?” 

“That’s because bugs are peculiarly nasty little problems that only come with software. It is easy to say what kinds of problems are not interesting: instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. The bugs creep in here. Some of the most fearsome of projects involve interfaces to a piece of software that is already full of bugs. Another is when you have to customize something for an individual client’s complex and ill-defined needs. To programmers these kinds of projects are the equivalent of being flogged by a thousand whips.” 

“A real tar pit, eh? Then why is it so attractive to some folks?” asks DeVito, curiously. 

“True, a real software project is a very messy affair. I have my doubts about calling it computer science,” says Bond shaking his head. “It’s just a bunch of driven, possessed people trying to build something before they are overcome by a tangled web of stupid, senseless, mindless, moronic, idiotic, dumb mistakes!” 

“The messy process is what many of us find objectionable, actually,” you say, reflectively, patting Bond on the back. “When you are entangled in the middle of it, you think it does not have to be this way. But that’s the way it is.” 

“And you only get one chance to do it right the first time,” groans Bond. “Especially the mission-to-Mars kind of projects. But, because you are a do-or-die artist, you say, ‘To hell with the pains, I want to write good code!’ and you plod on, regardless. They call it computer science, but it is not by a long stretch.” 

“There is a point at which it is science, Brooke,” you say. “For people who make the chip and the disk drive, there is a great deal of science, and not all of it is in hardware. It is also in the logic, in the hardware, microcode, etc. Then in the operating systems, that’s a little more towards science, though over time it becomes a big piece of software. The closer you get to applications, the less it is science.” 

“And why does that happen?” says DeVito, putting up his hands in a puzzled gesture. 

“Applications are where the real world, and real humans pop into the picture, complete with all their eccentricities and quirks. And when your carefully constructed program is used in the real world of humans, it does not ever have a chance to work perfectly the first time. The human world is a messy, unpredictable place,” says Bond, in a tone of exasperation. “As the technology columnist Robert Cringely said, programming today is a race between programmers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots.” 

“And to think that I have been designed by humans, oh my,” says DeVito, his eyes widening in imagined horror. 

“Oh, you have been tested and proven to work inside the messy human space of Baffle, Danny,” you say, soothingly. “The hardware is always easier to manage and tame. So we have science in it, most definitely. If that was not so, you would not be seeing these tremendous leaps in the capability of computers.” 

“Look at you, for example,” says Bond. “You are an advanced computer and nobody can say your hardware has a problem.” 

“I am sensitive too!” says DeVito. 

“So we keep noting, Danny. We have mastered hardware. But we have not made a corresponding advance in the ability to write software,” you say. “And humans have tried to turn that part of it into science for a long time. Top-down programming, object-oriented programming and various kinds of test techniques were supposed to solve it. We have tried to find scientific ways to write impeccable code, and all of that has not been very good at handling the mess.” 

“That’s where the problem comes in,” says Bond. “If computers were just hardware, it would be fine. But they are not. There are bugs in chips too. Now, for programmers, the distinguishing feature of wrestling with the nasty little bugs is that they do not learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software does not teach you anything, because the bugs are random. You never know what kind of bug will turn up next.” 

“So it is not just a need for keeping clean and error-free that makes good programmers avoid nasty little bugs like the plague. It is more a question of self-preservation. Working on nasty little problems does not make you any smarter. Good programmers avoid it for the same reason why models avoid fried food.” 

“And we have the smart programmer who avoids bugs but is not so smart around humans socially?”  says DeVito. 

“This is a stereotype—like all stereotypes, it has truth in it, that programmers are a group who are much better with machines than they are with people,” you say. “Of course, I have known many fine software guys who are well-rounded people. But in general it is true. I know programmers who have very formal ways of thinking and interacting with people—even with humanoids. They do not seem to read facial and bodily cues that well. Their work reinforces it. You get rewarded not for how well are with others but how well your code works.” 

“And it never works too well when the rubber hits the road, eh?” 

“The enemy is complexity, Danny. You get to a level of complexity in writing software where you just cannot make it clear and simple. It is not science when you are doing it.” 

“It feels like being on an accelerating high-speed train from which you are never able to get off,” groans Bond. “One more compile, one more bug; one more compile, one more bug. And on and on it goes.” 

“I dread to think of the process,” says DeVito, closing his eyes.