Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The High Cost of Interruptions

The High Cost of Interruptions

Leia em Português

This item in japanese


Chris Parnin, publishing under the name “ninlabs research”, has released a study of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio. His article, titled Programmer Interrupted, has found some worrying, but entirely unexpected, data points.

  • A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
  • When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
  • A programmer is likely to get just one uninterrupted 2-hour session in a day

Chris continues,

We also looked at some of the ways programmers coped with interruption:

  • Most sessions programmers navigated to several locations to rebuild context before resuming an edit.
  • Programmers insert intentional compile errors to force a “roadblock” reminder.
  • A source diff is seen as a last resort way to recover state but can be cumbersome to review

In order to determine a programmers “memory load”, Chris and his colleagues used a technique called pupillometry. In the 60’s researchers discovered that the pupils of the eye dilate when someone is working on a mentally challenging problem and constrict once a solution has been reached. This also occurs with other cognitive tasks such as memorizing and then reciting lists of words.

Another technique they used to measure memory load was subvocal utterances. In a related paper Chris wrote,

We found subvocal activity to be strongly associated with certain activites and conditionally during others. Subvocalization was strongly associated with making edits to code. During program exploration, we found limited subvocalization. Sub-vocalization mainly occurred when the subject encountered important code (logic for moving Tetris block) and (testing when block stops moving). We also found subvocalization when the developer was debugging and testing the program, which may be associated with problem formulation and solution evaluation.

Also discussed in the article is different types of memory and how they related to a programmer’s workflow. These include:

  • Prospective Memory, reminders to perform future actions in specific circumstances e.g. to buy milk on the way home from work
  • Attentive Memory, conscious memories that can be freely attended to.
  • Associative Memory, a set of non-conscious links between manifestations of co-occurring stimuli.
  • Episodic Memory, the recollection of past events.

Chris Parnin is a Ph.D. Student, College of Computing, Georgia Tech. He studies the empirical, hci, and cognitive neuroscience aspects of software development. I look at how software development occurs in practice and how certain tools help or hinder this process.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Rebuild the house of cards...

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    From personal reflection, solving a complex problem (programming or otherwise) first involves building a mental model which is like putting together a fragile house of cards.

    Any interruptions destroy the model/house (or context as described above) which you have to rebuild before you can be productive again.

  • tnereffid era sremmargorp laeR

    by Andras Ludanyi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Or you can be quite a reverse, being all the time in a programming mindset and when they "interrupt" you, you need 10 minutes to respond because you are still thinking about the code... ;)

    Idealist points of views are interesting, but the fact (in the real world) is that you must learn to dance in a middle of the storm, not to wait for a nice sunny day... if you want to be a productive programmer, you must be able to work in a middle of an "interruption", in a middle of the worst and most dynamic day you can imagine.

    Try to solve a problem (not too hard in the beginning), while watching two movies in the same time and trying to understand at least from "20000 foots above" the stories of both movies... it is hard at the beginning but after a few months, you will be able to do it, to know what was in the movies (not in great details though) and to solve the programming problem as well. After that, those interruptions will be a joke for you. The answer is always to train your brain, not to run and complain.

    Everything else is daydreaming...

  • Re: tnereffid era sremmargorp laeR

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I can write code while remaining attentive in some WebEx meetings (usually status updates) but that's about the limit of my multi-tasking.

    Some deep problems require undivided attention but you are probably right that we can train ourselves to respond faster.

  • Try Lean-Agile

    by Johnny FromCanada,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    More evidence for why one of the primary goals of Lean-Agile is to minimize interruptions to the Dev Team.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p