T

This is a continuation of Part 1 and assumes you’re already familiar with all of that.  Without further ado . . .

As much as I’d love to link to the study “A Peer Reviewed Double-Blind Test of the Maker and Manager’s Hypothesis:  Yes, Programmers Work Better Without Interruptions”, alas, no enterprising scientist has run that experiment just yet.  While waiting on them, however, there’s a rich body of work available on the concept of task switching.  The key difference between those two schedules is that managers rely on and embrace changing contexts, while (productive) programmers and writers run screaming away from that.

Task switching is what happens when you’re deep into one work state, and you get pulled away.  It can be self-inflicted when you take a coffee break and chat with your coworkers, or when you minimize your IDE and start browsing Reddit.  It can also be coworker/client/boss-inflicted when you get called, IM-ed, or physically nudged with an “urgent” request.

Note that I don’t include e-mail in that:  if you’re doing it right and disabling real-time popup notifications—and you should—then you control the interruptions.  If you’re having trouble on the email side, have a look at how stop email interruptions.

The day planner

Yeah, I’m being lazy and reprising the same image as in part 1 🙂

Any such interruption (whether self-inflicted or not) imposes what researchers call “reimmersion time” or “resumption lag,” depending on your source, which is the productivity/time cost of you resuming work and getting back to your original productivity.

Anyway, task switching is part and parcel of the typical modern office’s focus on multi-tasking, so you’ve almost certainly had to deal with it.  Unfortunately, our brains aren’t well suited to multi-tasking, and we incur a cognitive cost whenever we switch.  In some jobs, that’s not a huge deal; for example, in sales jobs, you generally want the “interruptions” of customers to interact with and, well, sell to.  Programmers don’t fare so well though.  Exhibit A:  “Impact of Task Switching and Work Interruptions on Software Development Processes” [1]“Tregubov, Alexey, Barry Boehm, Natalia Rodchenko, and Jo Ann Lane. “Impact of Task Switching and Work Interruptions on Software Development Processes.” In Proceedings of the 2017 International … Continue reading

Study Setup

This is a university study that tracked 68 graduate-level students who were tackling ten semester-long projects.  Those projects were real-life ones requested by nonprofits, entrepreneurs, and private corporations, who were the student’s clients.  So, while this took place in an academic environment, they weren’t abstract coding challenges but real-world ones that a professional developer would have otherwise addressed.

As part of their curriculum, the students already used Atlassian’s Jira tool, which is a well-known agile development manager.  In Jira, each student was assigned client coding tasks.  They were then responsible for providing daily work logs.  This was already something they were doing as part of their grad class, so the study didn’t impose any extra demands here.  What the study authors did add was teaching the students how to track reimmersion time and to add it to their already-mandated weekly reports.

The researchers made sure there was a mix of student obligations, as in addition to being responsible for their class project, various students had outside work and other classes.  They counted those external demands as extra projects, in the same way that at a company you might be 50% staffed on a primary project and 50% allocated to supporting other company projects.  This means some students had only a single project to track, while the most overbooked were juggling three, giving us plenty to divvy up.

Bringing it all together, they determined the cost of reimmersion = (total number of interruptions) * (reimmersion time).

Study Results

At the end of the semester, they computed and looked at these results:

  1. Average Number of Projects vs. Average Interruptions: the more projects any given student was on, the more interruptions they had (surprise, surprise, right?). The handful of students with one project naturally had zero interruptions, while those approaching three had nine, with the numbers pretty evenly divided in between.
  1. Average Effort (person hours lost to reimmersion time) vs. Average Number of Projects: yet again, more projects = more interruptions = more reimmersion time lost. The students with one project of course didn’t lose any time, while those approaching the max three lost nearly ten hours per week (on average).
  1. Quality of Work vs. Multitasking Overhead: they used the student’s grades and compared them to the effort spent on reimmersion. As you might expect, the students with less context switching had better grades on average.  You can then extrapolate that to the professional world by viewing the grade as quality of design, number of bugs, performance of algorithms, etc.

Breaking it down to fun stats, they concluded that splitting developers between two or three projects instead of a single one costs an average of 17% of their effort.  That means that for a proverbial forty hours a week employee, you’re losing ~6/7 hours of time to context switching.  Factor in that quality of work seems to decline, and it’s a dud deal for both parties.

Software development and context switching are a poor fit.  While I could have told you from personal experience—and I bet you’d agree—having some semi-objective science to fall back on is important when making your case to your client or boss.  I consider this study and all of its peers clear evidence in favor of Graham’s hypothesis, certainly from the maker’s side.  How about from the manager’s side?  I’ll examine just that in a future post in this series.

    References

    References
    1 “Tregubov, Alexey, Barry Boehm, Natalia Rodchenko, and Jo Ann Lane. “Impact of Task Switching and Work Interruptions on Software Development Processes.” In Proceedings of the 2017 International Conference on Software and System Process, 134–138. ICSSP 2017. New York, NY, USA: Association for Computing Machinery, 2017. https://doi.org/10.1145/3084100.3084116