Humour

Why deadlines can be deadly

T A Balasubramanian elucidates the principle of no-deadlines

After a long wait over many nail-biting weeks, Bobo Jitter, the perplexed CIO of Bazooka Company, finally gets back on the couch in the office of Dr Don Jong. Dr Jong is also called The Oddfather, given his propensity to come up with odd fixes for the treatment of technology-induced shaky conditions.

“So let me get back to our last session, Bobo. You were saying that doing what you enjoy is not easy, right? The rebel child in you would love to sit and blog all day, but dare not—you fear that the adult in you will be upset because that adult has this job as CIO to do. Is that correct?” says Dr Jong, gently.

“Right, Doc. But this child in me is nasty, sometimes, and gets me into frequent trouble.”

“And how does he do that?”

“You know, in my work, one of the most frequently asked questions—especially by those who depend on us for their programs—my users, is ‘When will the next version of my program be ready?’ And we, being under this kind of fire all the time, have a stock answer, which is always, ‘When it is ready and done.’ Which is not exactly what the user wants to hear. For example, Fin Fina, who heads our finance department with the iron hand of a tyrant, wants a specific date—preferably down to the minute and second. And our response drives him crazy.”

“Why is it so difficult to respond to such a request, can you say?”

“Because we believe that like children, we must be free to do things in a leisurely way. For example, one of the main principles we have evolved in Bazooka over the years is that, in program development, a program is released when it is ready. There are no deadlines, and my team will not give even a rough estimate of any release date.”

“Now where did you get this principle from, Bobo?”

“In his legendary essay ‘The Cathedral and the Bazaar’, Eric Raymond discusses this principle.”

“Why is this essay important?”

“Well, in this essay, he points out how the Leanox program was made by a community resembling a great babbling bazaar of differing agendas and approaches, out of which a coherent and stable system could seemingly emerge only by a succession of miracles. Unlike the systematic way that would be used to build, say, a grand cathedral. Seemingly built by rebel children, the Leanox system not only did not fly apart in confusion, but seems to go from strength to strength at a speed barely imaginable to cathedral-builders.”

“Ah, so you have here a successful role model for your rebel child in Bazooka?”

“Exactly, Doc. Raymond is my hero. He comes to the conclusion that in a programming project, as in any project, there are typically three expectations: the finished offering must have certain features; it must meet certain demands of quality; and it must be completed by a fixed deadline.”

“Very well, my boy. That is a reasonable expectation of anything one might be doing.”

“Well, Doc, the crazy thing is that these three demands—features, quality, and deadline—would build a certain tension into any project. If, for instance, the schedule is too tight, there may not be enough time to include all the features you want. But if a project manager behaves like a demon with his team, demanding that all the features are included and the deadline be met, then they are compelled to do a rushed job and, inevitably, quality suffers. Raymond concludes that by consciously abandoning just one of the demands, you can usually achieve good results on the other two.”

“Ah, I comprehend now. So this no-deadlines principle which you have taken to heart makes excellent sense. You would then be able to build all the features and all the quality your user wants to perfection? Even if it is delivered a few years after the deadline?”

“Correct, Doc. It is probably one of the reasons why Open Source programs are so successful. You can see, of course, that this no-deadlines principle is, of course, at odds with the project culture prevalent in Bazooka.”

“And possibly the rest of the business world, where it is usual to find not just one final deadline but several intermediate deadlines to be met at different stages along the way—rather like speed checks on a highway?”

“Right you are, Doc. Except that deadlines have the opposite effect of increasing speed if followed slavishly. That’s the word I want to emphasise—slavish. Sometimes, to be such a slave project manager is to find yourself having to give greater priority to working out, following up, and constantly re-evaluating schedules, than to doing the actual work. The work itself becomes of secondary importance, and my brain is filled with time management modules.”

“Surely, you have a problem here, Bobo. I experienced this myself not so long ago, when I was involved in a project for a large medical company. At the first meeting, the client did not even know in detail what the project was to be about. Making a precise list—defining the number of features—was to be part of the project. But the one thing that was clear right from the start was the schedule. Before we had even defined what we were to do, we were given a deadline. And the ‘well-justified’ reason for it was that the project had to be realised within two months because the funding had to come from the budget for the current quarter. I do not know if this is an indication of the usual priorities within that company, but I certainly found it abusing.”

“Amusing, you mean, Doc.”

“Yes, yes. Amusing it was. However, as the project deadline approached it became less amusing, and we made the finishing touches to the work late on a Sunday night. But the final project meeting was held within the specified time period, the invoice was sent on the last day of the quarter, and everybody was happy. Of course, this did require some self-deception, because we agreed to hold another meeting a few months later to sort out whatever had not been properly resolved by the time of the final meeting, and that turned out to be quite a lot.”

“You see, Doc? Self-deception. You said it yourself. Makes the child in you cry, eh?” “Ah, Bobo, we live with a world that is full of—how do you say—compromises?”

“Yes, you have it, Doc. Self-deception. Compromise. That’s what deadlines do to you.”

“There is, again, the tale of monkeys, Bobo. Two monkeys found a bunch of bananas and there was a fight, each wanting to get an equal share. So a third monkey came along, and set up a pair of weighing scales on which were placed the roughly split halves of the bunch. Now, first the scales tilted one way, so the third monkey ate one banana. The scales tilted the other way, so then the arbitrator ate another banana from the heavier side. Now this went on until the entire bunch was gone. So what does that mean, for us Bobo?”

“That it is better to be a little dishonest among ourselves and to compromise in the interest of getting things done, eh?”

“Voila! That is exactly what an adult would do. So, your project can be pronounced a success and you can say it has been completed on time—maybe the nick of time—but think of the warm amusing feelings your user will have for you.”