Saturday, 9 March 2013

Avoiding developer interrupts

I'm going to start posting here about our lean and agile development processes. They will fit more here than on the main Hedtek blog. A fitting start is the elimination of waste and in particular waste caused by developers not being 'zoned in' and focusing totally on development processes. Often this is called flow (Wikipedia has a great background article). Being in the flow has two aspects, of how to get into the flow, and avoiding interrupts which jerk a developer out of the zone or flow.

Positive ways of getting into the flow is something we haven't touched on so far, although we are aware of the need for and strive for a good working environment with relatively good levels of quietness. What we have been actively working on (with a good level of success) is avoiding unnecessary interrupts.

What is the problem with interrupts?  Don't you just hate it when you are six levels deep in code and your manager walks in to say to the team: "Hey guys, don't you think we should transmogrify the hubbleity widget?" Instant loss of concentration and exit from the zone, only to struggle to get back to where you were.

One research study (blog post, research paper) examined developer behaviour of 414 developers in 10,000 programming sessions and found that for developers in the sample

  • Devs took 10-15 minutes to resume editing code after an interruption.
  • Devs were likely to get only one uninterrupted 2-hour period for development in a day.

Both of these are alarming statistics. Avoid interruptions at all costs. As a practical measure we identified what each of our devs was doing when zoned in or not zoned in, and now we just look for these behaviours  before asking something. For example:

  • May be zoned in: Wearing headphones can be a sign of being zoned in.
  • Definitely zoned in: Not looking at ancillary sources for information on the web, and only focusing on and flicking between vi buffers or IDE tabs.
  • Not zoned in: Looking at a mobile (cell) phone.

Better still, we have adopted gmail chat and email for question requests, knowing that a developer will ignore these until having left the zone. Similarly, to remove more potential interrupts when I need to disappear from the office, theres a Where's Mark corner on one of our whiteboards, I simply write where I am and when I'm expected back there, and avoid the need to announce that to the dev team when I leave.

Of course pragmatism still rules, we can still interrupt, but we only use that for emergencies.

Additional sources

1 comment: