Have you ever noticed how, on certain workdays, the wheels of progress seem to turn backwards? Well, I've had entire months like that. If Peopleware, by Tom DeMarco and Timothy Lister, had been published about ten years earlier, I might have been saved from a lot of aggravation. (Assuming, of course, that I had the good fortune to stumble across the book, and then had the good sense to take it to heart.)
During my first few years as a full-time software developer and vendor, I made a concerted effort to be instantly available to my customers by phone. I tried to keep tabs on every facet of my company's operation, from managing inventory, to ad design and placement, to paying the bills. I selected an office suite with a few large rooms rather than many small rooms, free passage between the rooms, and little in the way of outside views, under the assumption that this would improve communication and minimize distractions. Ah, the follies of youth!
As the years went by, working conditions at my little company evolved. I moved the firm to another building, where each employee could have a sunny, private, and above all, quiet office. I arranged to screen out nearly all incoming phone calls, diverting technical support questions to electronic mail, a 24-hour electronic bulletin board, or a FAX machine. And I learned to delegate routine decisions about product promotion, purchasing supplies, and triaging of invoices to a trustworthy office manager.
What happened? Over a long period of time, I independently derived one of Peopleware's many axioms: "There are a million ways to lose a work day, but not even a single way to get one back." I also became alerted to the destructive influence of ambient noise and particularly of that demonic invention, the telephone. When I began to keep a call log, I realized how a relatively few telephone conversations, scattered through the course of a normal business day, could reduce the number of lines of new code generated that day nearly to zero. Peopleware describes and explains this phenomenon all too clearly:
During single-mindedwork-time, people are ideally in a state that psychologists call "flow." Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: "I began to work. I looked up, and three hours had passed." There is no consciousness of effort; the work just seems to, well, flow. You've been in this state often, so we don't have to describe it to you.
Not all work roles require that you attain a state of flow in order to be productive, but for anyone involved in engineering, design, development, writing, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well. Unfortunately, you can't turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly susceptible to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.
Once locked in, the state can be broken by an interruption that is focused on you (your phone, for instance) or by insistent noise ("Attention! Paging Paul Portulaca. Will Paul Portulaca please call extension ..."). Each time you're interrupted, you require an additional immersion period to get back into flow. During this immersion period, you're not really doing work.
If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call in flow time (work time) lost is twenty minutes. A dozen phone calls use up half a day. A dozen other interruptions and the rest of the work day is gone. This is what guarantees, "You never get anything done around here between 9 and 5."
DeMarco and Lister are justly famous for their texts and seminars on project management, structured programming, and software metrics. But in this slender, witty, and engaging book, they have put aside cold statistics and dataflow diagrams to concentrate on the human aspects of software development: Why some people are productive and others aren't; why some teams jell and others don't; why some strategies to increase quality and beat deadlines have the opposite effect; and why some working environments are conducive to timely, error-free programming and others hinder it. In many ways, Peopleware is a New Age counterpart of Frederick Brooks' legendary book, The Mythical Man-Month.
Most of the guidelines in Peopleware arise from the authors' personal experience, managing projects or consulting on project management for America's largest corporations. Other recommendations are derived from analysis of the "Coding War Games," an annual public competition which pits teams of implementors from different organizations against each other in the design, coding, and testing of a medium-sized program to a fixed specification. Overall, the book is written from an administrator's viewpoint, and directed at an administrator's concern. But there's hardly a page that wouldn't interest the individual programmer and consultant just as well. The book won't change your life, but it may improve it.