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

• 7 Tips for Programming in the Zone

• Keeping Developers in the Zone

• The Flow - Programming in Ecstasy

• Respecting the Zone

Testing Strategy part 3 - Acceptance Tests

After looking at code coverage and unit tests, I'd like to jump to the other end of the testing spectrum and examine what sort of Bayesian evidence an acceptance test provides. Again, this is skirting around the central question of "How can you demonstrate that your tests are correct?"

Helping others

It's an old cliche, but the saying 'if you want to learn a subject, teach it' holds a certain amount of truth. The act of ordering your thoughts and understanding about a subject allows you to spot the holes in your understanding, whether that subject is how to use a text editor or how nuclear fission works.

I've noticed this in many people, myself included. The primary case I would cite is the helpers in the IRC room #rubyonrails on freenode.net. The majority of newcomers will come into the room, ask a question, and leave (or remain silent) as soon as they have an answer. I've seen some of these people still asking the same sort of questions months or years after first appearing. The other newcomers are people that will ask some questions but will also try to answer other peoples questions straight away. These people have a tendency to develop all aspects of their development skills much quicker, as they are constantly exposing themselves to new situations that they would otherwise have never encountered.

Writing blog posts, doing podcasts, writing newsletters, helping out in a support channel. They're all ways to help teach other people and by extension help you to develop your own understanding further.

What are your preferences for helping develop the skills of team-mates, colleagues and your wider development community?