1

Resumption Strategies forInterrupted Programming Tasks

Chris Parnin Georgia Tech

Spencer Rugaber Georgia Tech

2

• Office studies– Interrupted tasks take twice as long.– 57% of tasks interrupted.

• Developer studies– Often blocked from completing tasks.– Case study estimates interrupts cost 15

minutes.

2

Problem

3

• Suspension– What is done before interruption.

• Cues– What tactile/visual reminders are present.

• Timing– Cognitive load and breakpoints.

Examples…

Key factors

3

Psychology Research

4

Resumption lag and interruption lag

4

Psychology research

ringing

breakInterruption lag Resumption lag

answer workreturn

5

When resuming a task….

Role of cues

5

Psychology research

Where to direct attention? What was I doing…

Finding: Marker (explicit) or cursor (implicit) better than no-cue

Psychology research

6

- breakpoint

- Interruptionpoint

Worst stopping point

Best stopping point

Finding: Stopping in deep within a subtask is worst because of higher cognitive load.

7

Knowledge– Plans and Steps– Designs– Sub-goals– Hypothesis– Issues– Exploratory– Unanticipated issue

7

Issues for Software Developers

Non-linear tasks– Exploratory– Unanticipated issue

8

• Is programming work fragmented and what is the cost?

• What strategies do programmers use to resume a task?

Research goal:Illicit requirements for better tool support.

8

Research Questions

9

Interaction history is “a record of programming activity”

and consists of events:- timestamp- target (code entity)- type (edit, search command, file selection)

events can be grouped into sessions:“A timeframe of work”

Interaction History and Concepts

9

Investigation

10

Sessions

10

Investigation

session

1 hour

• New session when greater than 15 minutes.• 98% events within a minute of another.

11

Datasets

11

Investigation

Dataset Stats

Users Sessions Events

Visual Studio [1] 12 1972 573,998

Eclipse [2] 73 7927 3,937,526

Total 85 9899 4,511,524

[1] - ICPC 06, Parnin Görg[2] – IEEE Comp. 06 Murphy, Kersten, Findlater

12

Edit Lag: a cost measure

12

Investigation

E EEEEE

Session interruption Session

E EEEEE

Edit lag

13

• Method– Fragmentation?

• Group events into sessions (15 minutes).• Histogram session length.

– Edit lag• Choose sessions with at least 1 edit event.• Find first edit event.• Measure offset from start of session.

Work fragmentation and edit lag

13

Analysis

14

sessions Programming sessions in a typical day

sessions 1-3 1-2 1-2 1 0-1 rarely

duration 15m 30 m 1h 2h 4h 8h+

Work fragmentation and edit lag

14

Analysis

Based on: 25% - 75% percentile.

15

• Method– Pilot survey on strategies.– Measure

• strategy usage frequency.• edit lag with strategy.

Strategies

15

Analysis

16

• “Return to last edit”• “Navigate to remember.”• “Examine program execution/output”• “View compile errors”• “Use version history (diff/comments)”• “Use task list”

Strategies

16

Analysis

17

• Frequency: Last edit location– 17% sessions resume coding last location:

• 56% involve navigations to other locations.

Last Edit

17

Analysis

Sessions 35% 22% 23% 12%

Edit Lag 1m 1-5m 5-15m 15-30m

18

• Frequency– 83% sessions involve navigating first.

• Navigations– 2 - 12 (7) locations.– 4 - 40 (27) navigation distance.– 15 - 150 (135) selection events.

Cost of Navigate to Remember

18

Analysis

Sessions 16% 25% 22% 18% 8%

Edit Lag 1m 1-5m 5-15m 15-30m 30-45m

19

• Views– Task lists 9%.– Error lists 9%.– Revision history notes/diff 4%.

Other cues

19

Analysis

20

• Programmers seek breakpoints:– Often resume coding in new locations.– But, lag to resume next part of task.

• Last location insufficient:– 56% still need navigation,– must navigate several locations before coding.

• Other cues are used:– Compile errors, version history, task lists…– But are still ad-hoc.

20

Implications

21

• 43 professional developers (so-far)– Several major companies

• Resumption lag– Typical resumption: 10-20 min– Worse resumption: 30 min – days

• Preparing for interruption– “personal (private) blog, electronic sticky notes,

failing test, intentional compile errors, debugger breakpoints, remember order of tasks, take continuous notes, notes in source code”

Survey (on going)

21

Recent Research

22

Task Tracking

22

Recent Research

• Few projects are using issue trackers for programming tasks: – Only 3 out of 59 projects had over 100 tasks.

• Survey: 41% say tasks are frequently broad in scope and needs to be refined into many subtasks.

• Few track subtasks– Less 1% Mylyn users created new subtasks.– Only 4 out of 59 projects track subtasks.– But 13% of task descriptions had manual task breakdowns.

• Many developers prefer personal tracking separate from official tracking. (notepad)

23

23

Future ApproachesTask Board Activity Timeline (retro-active)

Task Pad

24

• Investigate relation of sessions:

• Eye-tracking at start of session.

• Deeper analysis on activities.

24

Future Research

25

• Programmers are affected by interruptions but have limited cues for resumption.

• Programmers value taking notes but have limited tool support.

25

Conclusions

26

Filtered Edits

1561 1213

5931 3962

7492 5175

26

27

Limited availability of cues

27

Issues for Software Developers

28

28