The deadliness of deadlines

Linus Torvalds created the Linux operating system and is still in charge of Linux development. After graduating in computer sciences from the University of Helsinki in February 1997, he went to work for a California-based company called Transmeta. At the same time, Linux was becoming a relatively mature operating system, and was beginning to get attention from the press. When Linus moved to the United States it gave the American media far greater access to him, and thus the shy nerd was suddenly transformed into poster boy for the entire Open Source movement.

One of the most frequently asked questions at the time was, "When will the next version of Linux be released?' Linus had a stock answer, which was always, "When it's done.'

Long before Linus joined up, one of the mainstays of Open Source program development was that a program is released when it is ready. There are no deadlines, and the developers won't give even a rough estimate of any release date.

In his legendary essay "The Cathedral and the Bazaar', Eric Raymond discusses this principle.1 He comes to the conclusion that in a programming project, as in any project, there are typically three expectations: the finished product must have certain features; it must meet certain demands of quality; and it must be completed by a fixed deadline.

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 leans on 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.

In the light of that, the Open Source community's no-deadlines principle makes excellent sense, and is probably one of the reasons Open Source programs are so successful. This no-deadlines attitude is, of course, at odds with the project culture prevalent in the rest of the business world, where it is usual for there to be not just one final deadline but also several intermediate deadlines to be met at different stages along the way. Sometimes, to be such a 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, thus the work itself becomes of secondary importance.

I experienced this firsthand not so long ago, when I was involved in a project for a large Finnish IT company.2 At the first meeting, the client didn't 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'd 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 realized within two months because its funding had to come from the budget for the current quarter. I don't know if this is an indication of the usual priorities within that company, but I certainly found it amusing.

However, my amusement lessened as the project deadline approached, 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. But that's fine - better to be a bit dishonest among yourselves than to compromise on quality. So, the project was pronounced a success and said to have been completed on time.

Quality and quantity of features are factors of the corporate world and of production. Perhaps some project manager will employ Eric Raymond's way of thinking in their next project. But more important is to understand the influence of deadlines on our own lives. To many people a deadline can seem like a matter of actual life or death, and they feel impelled to work like crazy late into the night to meet it. And very often this life-or-death deadline is totally arbitrary or - as in my own case - is fixed to comply with some utterly unproductive bureaucratic detail. And for that we allow ourselves to become so stressed?

Linus has tried to sort out his own approach to work in a principle he dubbed Linus's Law. It answers the question: why do people do things? The first reason is survival. The second reason is to have social life. And the third reason is that people do things for fun. In that order.

Linus's Law can be applied to work. Primarily, people work to earn enough money to buy food and pay to keep a roof over their heads. But if these were their only motivations, people could work a lot less than they do today. Somebody once said if it were only a question of getting the sustenance for survival, people in the Western world wouldn't need to work more than a few hours a week. By Monday afternoon, we'd have earned the essential part of our income. And in a welfare state like Finland, odds are one could survive one's entire lifetime without working at all.3 But people still want to work. Why?

Work provides people with a social life. School and the workplace are where most of us get to know our best friends. So, that's the social-life motivation. And most people strive to get a job they think they will enjoy doing. So, they work for fun.

Since we work to have fun, to enjoy it, then why do we drive ourselves into the ground trying to meet artificial deadlines? Why work like drudges, as if it really is a question of life and death? Linus feels there's no sensible reason for it. You ought to enjoy work, because that's why you do it. Once again, it's clear that deadlines are bad for both the worker and the work itself.
Linux 2.2 was finally released on 25 January 1999. And almost immediately speculation was rife about when the next version, Linux 2.4, would be released.4 By the time version 2.6 was released the press had learned to be patient, and nobody had bothered to ask Linus for a release date. The media had learned something. You, too, could try learning something from Linux. Take it easy and enjoy what you do.

• 1https://catb.org/~esr/writings/cathedral-bazaar/
• 2Unfortunately, I can't tell you the name of the company or about the project because, of course, the contract included a non-disclosure clause.
• 3Naturally, everyone survives their entire life. :-) What I mean is that it's possible to live to become a pensioner without ever working a single day. Most people, however, don't want that sort of a life.
• 4Linux versions are always denoted by even numbers. Odd numbers are development versions for programmers.