Developers are commonly believed (and I agree) to enter a state of focused work that is commonly called “flow” (not to be confused with Flow in LEAN). Flow, for developers, means that they work at a higher productivity level, with fewer defects, because they can work uninterrupted.
Intuitively, this makes sense. It’s much easier to work on almost anything if nobody is bugging you. This need for flow has encouraged some developers to post signs outside their workspace – “do not disturb!” I too, when analyzing a data set, have fallen into a flow where I seem to be able to get a lot done. At some point in time, I get stuck, usually when I have an unanswered question about some content in the data or missing data that I need input for.
When I hit these points, I reach out to whatever contacts I have to try and get a speedy answer. My flow has been interrupted, and to restore it I need to get the missing piece of information so I can get back to work. In fact, a great deal of my job depends on these little moments of discovering what I don’t know and then going to find the answer.
When I used to program, I’d often find this to be the case as well. Systems I worked on were quite large, so it wasn’t uncommon to run into a section of code I had never visited before. Still, I usually knew who did know about that section of the code so I’d reach out to that person to fill in some knowledge gaps for me.
My anecdotal experience about both entering flow and it getting interrupted made me ponder something. Is allowing a developer to post a “do not disturb” sign to maintain flow really the best thing to do? Sure, we all want to eliminate unnecessary distractions, but what about distractions which could help someone else get on with their day? What if the distraction isn’t a phone call from your spouse asking you to pick up milk on the way home (something that could wait) and instead is a question that if unanswered will either block or at least greatly delay a coworker?
Being a data person, my reaction was to simulate it, so I built a simple model. Here’s how it works. A team can have any number of developers (I used 5, 10, 15, 20 and 25 for my graphic). For each minute of the day a developer may randomly have a moment of self-interrupted flow – a realization that they need some piece of missing information from another developer. The model then allows for two possibilities. One model allows the developer to go ahead and interrupt another random developer to get the answer. If the developer can interrupt another, both developers pay a random amount of lost productivity (5 to 30 minutes I made it) PLUS another penalty of 15 minutes (a number I’ve heard quoted before) to regain flow. The alternate model does NOT allow for the developer to interrupt another developer. Instead, that developer becomes blocked until a certain time of day when all developers stop (namely lunch or the end of the day).
At the end of the day, we simply count up the total number of minutes that all developers were in a “flow” state. You can see the results in this g raphic. The red square dots represent the model where interrupting another developer is allowed. The black circles represent the model where interruptions must be held until pre-determined times of day.
Notice, regardless of the size of the team, when the rate of interruption per minute is relatively low (about a 1% to 5% chance per minute that you’ll be interrupted), it is better in this model to interrupt another developer with your question. Essentially, the amount of time wasted by one developer waiting to get the information they need hurts more than the cost of the interruption to both parties. Even though two resources aren’t getting anything done for some amount of time, it’s better that they both can get back to work and make progress.
Beyond that break even point of 5% interruptions, not breaking flow is somewhat better, but not much. In those higher rates of needing help, regardless of which way you go nobody makes much progress. Allowing some developers to have flow in those cases entirely wastes another developer’s time, but the interruptions would become so frequent that nobody can do work either.
Clearly, this model is far from perfect, but it is instructive. One should not allow developers to have “flow” at all costs. While it is good for the individual developer, it is worse for the team as a whole. And while all interruptions don’t come from developers (managers have questions too), I think it’s fair to say that if not getting the question answered would block your progress for longer than the time to regain flow then it a good choice to interrupt. The black and white of “don’t interrupt” is easy to remember, but the outcome may not be as desirable as we imagine it to be.