By way of summary, here’s a metaphor for thinking about the communication behavior that these studies document. We can think of a programmer as a thread scheduler in an operating system. The “algorithm” of a programmer’s work practice is sketched in Example 16-1.

To flesh out the metaphor, here’s a quick and dirty overview of how an operating system schedules threads. The scheduler keeps a queue of threads that are ready to run. It picks one and runs it until that thread gets blocked on input.^[21] The blocked threads then get put on the pending queue until the input is available. Input arrives asynchronously in the form of an interrupt (for example, a network packet arriving or a disk block getting copied to memory). When input arrives, the scheduler finds the thread that was blocked waiting for that input and moves that thread from the pending queue back to the active queue. After handling the interrupt, the scheduler goes back to running a thread from the active queue.

void beProductiveProgrammer()
{
   while (!quittingTime)
      try {
         var task = readyTasks.pickOne();
         while (!task.isDone && !task.isBlocked)
            task.makeProgress();
         if (task.isBlocked)
             blockedTasks.add(task);
         readyTasks.remove(task);
      }      catch (Interruption interruption) {
         var info = interruption.informationContent;
         for (var task in blockedTasks)
            if (task.blockedOn(info)) {
                blockedTasks.remove(task);
                readyTasks.add(task);
            }
      }
}

This thread scheduling behavior is strikingly similar to the work practices observed in the studies in this chapter. A programmer carries out a programming task (the thread) until she can’t make further progress without getting some information (the thread is blocked on input). She then puts this task away and picks another one to work on to keep from being idle. When an interruption happens (an in-office visit, a phone call, an incoming email), this interruption often carries relevant information, such as the answer to a question that was posed. When this information arrives, the programmer can then resume the task that was blocked waiting for that information.

Naively, we could think of the inner loop as being a programmer’s only “productive time.” However, as the studies discussed earlier show, this view isn’t realistic. Programmers stay in the inner loop only when they have no questions or can immediately find the answers without having to communicate with others. But these studies show that many times a day, programmers do have questions that require communication. A major source of such questions is the need for rationale information, which often is recorded only in the team’s collective memory.

Could we ever hope to eliminate such questions, say, through good documentation? Economically, we wouldn’t want to do this. A development team collectively makes thousands of choices each day, ranging in scope from tiny decisions about local variable names up to decisions about requirements or architecture that affect the entire product and team. As a project matures, some of these decisions will be revisited over and over again, while others are made once and remain stable. So documentation amounts to speculative investment (or, put more crudely, gambling). It’s worthwhile documenting a decision only when these conditions are met:

All of these conditions are speculative and uncertain. Looked at this way, we can see that many teams do their best to invest wisely in documentation in the face of uncertainty. They write documentation about the decisions with the biggest scope, most stability, and widest audience. The rest they handle on-demand through communication.