Humour

Crunch time for IT

T A Balasubramanian on why working more hours does not make software projects go any faster, only exhausted programmers land up making more mistakes

Once again, Bobo Jitter, the perplexed CIO of Bazooka Company, is back on the couch in the office of Dr Don Jong. Dr Jong, known to his admirers as The Oddfather, has a disconcerting ability to come up with tangential solutions for decoding the never-ending puzzles that keep popping out of technology’s frontiers.

“So what seems to be the cause of … ah, your present state of unseemly unrest, Bobo?”

“Well, Doc, it is the matter of delays. I have been pressing my software project team leader, Brooke Bond to work faster on some of the critical projects he is handling, but he has been … well, putting up a stiff resistance.”

“Ah, rebellion in the ranks again, my boy?”

“You could say so, Doc. On the other hand, I am perpetually required to provide a meaningful reply to questions such as ‘When will the application be ready for use?’ However, the usual glib answer, such as ‘It will be done when it is done’ does not endear me to anyone. Now, Bazooka Zinca, our CEO, wants me to hammer down a date for the conversion of our old finance system into the latest version. I will surely lose my job if I give him our stock response.”

“Of course you will not,” says Dr Jong, soothingly. “And Bond, of course continues to maintain that software developers are artists, not scientists?”

“Yes. In fact, last week, he told me, and I quote, ‘Software development is an artistic process that must be given freedom to evolve over an unspecified time. When you ask an artist to create a work of art, such as a sculpture or a painting, would you ask for a schedule? No. You would wait until the artist believes he has finished.’ Now I ask you, how am I supposed to get this project done by the end of four months?”

“By letting him know that you are not going to rush things.”

“What? If I do not keep after him, he will carry on this way till next year—maybe a year after that, too.”

“Absolutely not. Just insist on Bond and his team working no more than five eight-hour days for a 40 hour week. And you can also tell him that you believe he needs to take plenty of rest each day.”

“No way, Doc. You have no idea how rested Bond can become if I let him slacken.”

“All right, assume that you wish to crunch the project your way. Let me play this scene out for you. Let us say you expect this project to take six months with a sedate 40 hours a week to complete. If you push all the buttons and make Bond and his team work 60 hours a week, you could—in theory—be able to wrap up the development in four months flat. The entire team may even whoop at this challenge because it will make them all look like supermen. ‘Look at the Bond team—they are here every weekend’ would be a refrain across Bazooka, eh?”

“Exactly my sentiments, Doc. This should work, right?”

“Ah, Bobo, how smugly you build castles in the air! Think again. In most times, places, and industries over the past century, managers who worked their employees this way would have been tagged as slave-drivers—not just because of the hazards they pose to good worker relations, but also because of the risk that their aggression poses to the company’s productivity and useful hands. A hundred years of industrial research has proven beyond question that exhausted workers make errors that blow schedules, damage equipment, create cost overruns, erode product quality, and eventually eat into the bottom line—not exactly pictures that a CEO would like to contemplate.”

“These are changing times, Doc. We are talking of IT services here, so my projects are all about mental work …”

“This is even more taxing than physical work, my boy. There are dozens of research tomes that will tell you how working more hours does not make software projects go any faster. Software design takes huge intellectual exertion—but of course you know that. Even your best programmers cannot keep up that level of effort for more than a few hours a day. They need to divert their brains every now and then, which is why they are surfing the Internet or playing games when you see them—apparently at work. Programmers produce more good code and fewer bugs when they relax and chill out. They are almost like us psychiatrists in the way they work. We take the first hour or so of the day getting into the groove. The next few hours tend to be our best ones. Later in the day, as we get tired, we get less done per hour.”

“Well, Doc, that I can understand. I have done my share of coding too, you know. It takes a long time to fix a simple bug or add a simple feature that I would have handled in minutes earlier in the day.”

“So you see? We are getting somewhere now. Now imagine being pushed just a little farther—and it seems that much of the computer gaming industry is becoming useful as a diversion at this extreme most of the time—an overstretched programmer may delete valuable files—requiring extra work to restore backups—or maybe even have an accident on the way home that takes him offline for months. The point is that productivity varies over the course of the workday. After enough hours, productivity approaches zero—eventually it becomes negative. Laboratory studies show that mental work declines by 25% during each successive 24 hours of continuous wakefulness. So a time crunch raises the odds of a significant error. Imagine sending out software that erases a customer’s hard drives, or deleting the source code, or spilling liquid into a server that has not been backed up recently.”

“Well, Doc, it seems clear that pushing a programming team by crunching project time does tend to backfire. But how do I convey a certain urgency to Bond? After all, he tends to look upon all deadlines with the disdain of the artist.”

“Ah, Bobo, so what we are really up against is this challenge posed by the insolent Bond to your position as CIO, are we not? It is not as if you are hell-bent on the project happening on time because it would cause great harm to Bazooka if it did not. You want to be seen as the CIO who delivers, eh?”

“Well, come on Doc, you know I have to prove my worth to my CEO…”

“So the time crunching is your sprint of honor to prove your worth, eh? You decide to crunch because you want to be able to tell your big boss ‘I did everything I could.’ You crunch because you value the programming backsides sitting for a certain time every week in their chairs more than the needs of the brains creating the software.”

“Ouch! You don’t mince words, but you’re right, Doc. It seems that I might not have been considerate about the job being done or the people doing it.”

“Voila, you comprehend! So some managers like to crunch time because they have learned only the importance of appearing to do their best—instead of actually doing their best. And maybe they crunch because, back when they were programmers, or testers, that was the way they were taught to get things done.”