There’s been some online chatter recently about an old topic – the need for uninterrupted focused work time when doing software development. Some of the comments have surprised me, in part because I thought it was a settled topic. That was silly of me, because of course there are no settled topics.
But it surprised me, as well, because some of the comments suggested a fundamental misunderstanding of how creative work is done: Some people treat creative work the same as repetitive tasks, such as sweeping the floor or washing the dishes, in that they assume creative work can be interrupted over and over again without any cost.
Several points of view came out in various online discussions, including:
- Arrogant developers think their time is sacred, and don’t want to be interrupted even for a few seconds to answer an important question.
- I (the person on social media) want to be interrupted by my team mates so that we can collaborate, rather than just sitting there coding all by myself all day.
- If you keep a large, complicated model in your head, then every time you’re interrupted you’ll lose track of where you were, and have to start over to some extent. Solution: Use development methods that relieve you from keeping the whole solution design in your head (e.g. emergent design).
- In the best places I (the person on social media) have worked, people felt free to walk to each other’s desks and talk with them at any time. It would be bad if this were discouraged or prohibited.
- According to Scrum, stakeholders are only allowed to talk to the team during specified Scrum events. Otherwise, they are to leave the team alone.
- Paul Graham’s concept of manager time and maker time. In a nutshell, a manager’s day comprises one-hour time slots for meetings. If they have to move a meeting to a different time slot, doing so has no impact on their work. A maker’s day comprises blocks of time for focused work, typically extending well beyond a single hour. To remove a maker from their environment in the middle of the morning for a brief meeting destroys the morning. Do it again in the afternoon, and you’ve destroyed their entire day.
- Czikszentmihaly’s concept of flow – creative work requires long periods of uninterrupted focus. When focus is broken, it takes time for the person to recover to the point where they were before the interruption. There’s an increased chance they will forget something or make mistakes.
- Context-switching overhead – every context switch event causes a delay before the person gets back to the point where they were before the event.
Some thoughts on these perspectives, FWIW:
Arrogant developers. A person who interprets a request for uninterrupted time for focused work as “arrogant” lacks an understanding of the creative nature of software-related work. This attitude reflects a poor understanding of the difference between creative work and repetitive tasks, or perhaps a misunderstanding about the fact that software development is, by its nature, creative work. So, I think this is a misunderstanding of software development and isn’t relevant to the problem of interruptions. It’s a potential learning opportunity for the interrupter, if they are inclined to take advantage of it.
Interrupted by team mates. This represents a misunderstanding of how collaborative work is done, and of what constitutes an “interruption.” As software development is largely a collaborative activity, when team members talk to each other and work together it isn’t an “interruption” at all…it’s “the work.” The work is interrupted when someone who is not on the team and not part of the current collaborative activity causes the work to pause so that they can ask a question or conduct some other business with one or more team members.
Mental models. We all keep models of software design in our heads, even when we try not to. For novice practitioners, this may indeed be the whole solution they’re currently working on. Experienced practitioners who use generally-accepted good practices may not appear to be holding model solutions in their minds as they incrementally emerge a design, but in fact their heads are full of patterns for software designs, accumulated over many years of creating solutions. They apply self-discipline to try and avoid being fooled by their own assumptions about how the design should emerge, but this is easier said than done. So, I think this isn’t relevant to the problem of interruptions.
Use development techniques that mitigate the cost of interruptions. It may (or may not) be true that by building a suite of fine-grained executable examples, and by using collaborative methods like pair programming, we can regain flow faster after an interruption, but in any case we still lose flow and we still have to regain it. If people interrupt many times in the course of a day, it hardly matters whether recovery is fast or slow after each event. So, I think this isn’t relevant to the problem of interruptions.
Scrum says “Don’t talk to the team.” This represents a rigid (and incorrect) understanding of Scrum. The idea that we should try not to add work mid-sprint doesn’t mean that no one is allowed to communicate with the team. So, I think this is a misunderstanding of Scrum and isn’t relevant to the problem of interruptions.
Manager time vs. maker time. Graham’s model is somewhat subjective and based on observation rather than research, but many software developers relate to it. I have observed that many people who work with software teams, but who are not themselves software developers or testers, lack a gut-level understanding of how the work feels. They may not appreciate the impact of an interruption, however brief. It’s the number of interruptions rather than their duration that destroys flow. Twenty interruptions lasting just a few seconds each probably have a more debilitating effect than a single hour-long interruption in the course of a day.
Maintaining flow. Like any creative work, effective software development requires long periods of steady focus. Interruptions incur costs in terms of lost time, increased fatigue, and more errors.
Context-switching overhead. Even when the interruption is brief (say, to answer a quick question), it causes a context-switching event in the mind of the person who is interrupted. The cost of context-switching is well known and amply documented.
Conclusion
A balanced approach recognizes the need for uninterrupted focus as well as the need for communication with team members. Set aside periods of time for focused work, and well-known times for interaction with the team. Example: If focused work is time-boxed in 90-minute intervals, people who need to ask developers a question will never have to wait more than 90 minutes to ask their question, and on average only 45 minutes.
Resist the temptation to respond to emails or Slack or other communication channels during these focused work periods. The world will not come to an untimely end if you don’t see a message for 45 minutes.
It’s possible, but highly unlikely, that a question can’t wait until the end of the current time-box. In most organizations, even the most trivial task requires well over 90 minutes to complete, due to dependencies between functional silos and/or narrowly-defined roles, as well as the tendency for people to overbook their time. Given the general inefficiency of most organizations, the constraint for getting things done is almost never the immediate availability of a developer to answer a question. The desire to ask a question right-the-hell-now-no-matter-what may be strongly felt, but is probably not constructive overall.
It’s also worth remembering that your single interruption is probably not the only one the team will experience in the course of a day. Trying to focus for 90 minutes on a creative task when you’re interrupted every 3 minutes for a “quick question” is very frustrating and is not an effective way to get the work done. By insisting on interrupting whenever you please, you’re not elevating yourself above a single arrogant developer who needs a lesson in humility; you’re elevating yourself over the organization’s return on investment of the developer’s work.
My suggestion: Be cognizant of the cost of interruptions and ensure the urgency of getting the answer really exceeds the value of the work you’re interrupting. If you can wait 45 minutes (on average) and still get what you need, then why interrupt the work? Thinking about it in this way is helpful whether you’re right or wrong about the urgency of your question. If you’re wrong, this kind of analysis can help you recognize the fact before you incur the cost of interrupting the team (and please understand you’re not interrupting just one person, if the team is using contemporary collaborative working methods). If you’re right, you’ll be able to justify the cost of the interruption to senior management in your organization in terms they can understand: return on investment. Everyone wins.