My slides for the presentation of our full technical paper at ICPC 2015 (International Conference on Program Comprehension). Abstract–Developing software is a complex mental activity, requiring extensive technical knowledge and abstraction capabilities. The tangible part of development is the use of tools to read, inspect, edit, and manipulate source code, usually through an IDE (integrated development environment). Common claims about software development include that program comprehension takes up half of the time of a developer, or that certain UI (user interface) paradigms of IDEs offer insufficient support to developers. Such claims are often based on anecdotal evidence, throwing up the question of whether they can be corroborated on more solid grounds. We present an in-depth analysis of how developers spend their time, based on a fine-grained IDE interaction dataset consisting of ca. 740 development sessions by 18 developers, amounting to 200 hours of development time and 5 million of IDE events. We propose an inference model of development activities to precisely measure the time spent in editing, navigating and searching for artifacts, interacting with the UI of the IDE, and performing corollary activities, such as inspection and debugging. We report several interesting findings which in part confirm and reinforce some common claims, but also disconfirm other beliefs about software development.

1. I Know What You Did Last Summer
An Investigation of How Developers Spend Their Time
Roberto Minelli, Andrea Mocci, Michele Lanza
REVEAL @ Faculty of Informatics — University of Lugano, Switzerland
@robertominelli

2. write

3. write
read

4. write
read
navigate

5. write
read
navigate
user interface

6. write
read
navigate
user interface
program
understanding

7. write
read
navigate
user interface
program
understanding
Program understanding:
Challenge for the 1990s
In the Program Understanding Project at IBM's Re-search Division, work began in late 1986 on toolswhich could help programmers in two key areas: staticanalysis (reading the code) and dynamic analysis (run-ning the code). The work is reported in the companionpapers by Cleveland and by Pazel in this issue. Thehistory and background which motivated and whichled to the start of this research on tools to assistprogrammers in understanding existing program codeis reported here.
" If the poor workman hates his tools, the goodworkman hates poor tools. The work of theworkingman is, in a sense, defined by his tool-witness the way in which the tool is so often taken tosymbolize the worker:the tri-squarefor the carpenter,the trowelfor the mason, the transit for the surveyor,the camera for the photographer, the hammerfor thelaborer, and the sickle for the farmer.
"Working with defective or poorly designed tools,even the finest craftsman is reduced to producinginferior work, and is thereby reduced to being aninferior craftsman. No craftsman, ifhe aspires to thehighest work in his profession, will accept such tools;and no employer, if he appreciates the quality ofwork, will ask the craftsman to accept them. "I
Today a variety of motivators are causing corpora-tions to invest in software tools to increase softwareproductivity, including: (1) increased demand forsoftware, (2) limited supply of software engineers, (3)rising expectations of support from software engi-neers, and (4) reduced hardware costs.' A key moti-
by T. A. Corbi
vator for software tools in the 1990swill be the resultof having software evolve over the previous decadesfrom several-thousand-line, sequential programmingsystems into multimillion-line, multitasking "busi-ness-critical" systems. As the programming systemswritten in the 1960s and 1970s continue to mature,the focus for software tools will shift from tools thathelp develop new programming systems to tools thathelp us understand and enhance aging programmingsystems.
In the 1970s, the work of Belady and Lehman"?strongly suggested that all large programs wouldundergo significant change during the in-servicephase of their life cycle, regardless of the a prioriintentions of the organization. Clearly, they wereright. As an industry, we have continued to growand change our large software systems to:
• Remove defects
• Address new requirements
• Improve design and/or performance
• Interface to new programs
• Adjust to changes in data structures or formats• Exploit new hardware and software features
As we extended the lifetimes of our systems bycontinuing to modify and enhance them, we also
e Copyright 1989by International BusinessMachines Corporation.Copying in printed form for private use is permitted withoutpayment of royalty provided that (I) each reproduction is donewithout alteration and (2)the Journalreference and IBM copyrightnotice are included on the first page. The title and abstract, but noother portions, of this paper may be copied or distributed royaltyfree without further permission by computer-based and otherinformation-service systems. Permission to republish any otherportion of this paper must be obtained from the Editor.
…up to 50%

8. write
read
navigate
user interface
program
understanding
workman hates his tools, the good
hates poor tools. The work of the
in a sense, defined by his tool-
in which the tool is so often taken to
orker:the tri-squarefor the carpenter,
e mason, the transit for the surveyor,
he photographer, the hammerfor the
sickle for the farmer.
defective or poorly designed tools,
craftsman is reduced to producing
nd is thereby reduced to being an
n. No craftsman, ifhe aspires to the
is profession, will accept such tools;
r, if he appreciates the quality of
e craftsman to accept them. "I
of motivators are causing corpora-
software tools to increase software
uding: (1) increased demand for
ed supply of software engineers, (3)
s of support from software engi-
uced hardware costs.' A key moti-
hat all large programsundergo significant change during the inphase of their life cycle, regardless of the aintentions of the organization. Clearly, theright. As an industry, we have continued tand change our large software systems to:
• Remove defects
• Address new requirements
• Improve design and/or performance
• Interface to new programs
• Adjust to changes in data structures or form• Exploit new hardware and software feature
As we extended the lifetimes of our systecontinuing to modify and enhance them, w
e Copyright 1989by International BusinessMachines CorpoCopying in printed form for private use is permittedpayment of royalty provided that (I) each reproductionwithout alteration and (2)the Journalreference and IBM conotice are included on the first page. The title and abstract,other portions, of this paper may be copied or distributedfree without further permission by computer-based andinformation-service systems. Permission to republish anyportion of this paper must be obtained from the Editor.

9. write
read
navigate
user interface
program
understanding
workman hates his tools, the good
hates poor tools. The work of the
in a sense, defined by his tool-
in which the tool is so often taken to
orker:the tri-squarefor the carpenter,
e mason, the transit for the surveyor,
he photographer, the hammerfor the
sickle for the farmer.
defective or poorly designed tools,
craftsman is reduced to producing
nd is thereby reduced to being an
n. No craftsman, ifhe aspires to the
is profession, will accept such tools;
r, if he appreciates the quality of
e craftsman to accept them. "I
of motivators are causing corpora-
software tools to increase software
uding: (1) increased demand for
ed supply of software engineers, (3)
s of support from software engi-
uced hardware costs.' A key moti-
hat all large programsundergo significant change during the inphase of their life cycle, regardless of the aintentions of the organization. Clearly, theright. As an industry, we have continued tand change our large software systems to:
• Remove defects
• Address new requirements
• Improve design and/or performance
• Interface to new programs
• Adjust to changes in data structures or form• Exploit new hardware and software feature
As we extended the lifetimes of our systecontinuing to modify and enhance them, w
e Copyright 1989by International BusinessMachines CorpoCopying in printed form for private use is permittedpayment of royalty provided that (I) each reproductionwithout alteration and (2)the Journalreference and IBM conotice are included on the first page. The title and abstract,other portions, of this paper may be copied or distributedfree without further permission by computer-based andinformation-service systems. Permission to republish anyportion of this paper must be obtained from the Editor.
Does this myth hold?

10. The Pharo IDE
Enter some B$ about Pharò

11. The Pharo IDE: Debugger
Enter some B$ about Pharò

12. Enter some B$ about Pharò
The Pharo IDE: Code Browser

13. IDE Interaction Data
IDE developer
interactions

14. DFlow
MetaUser InterfaceLow-Level
Opening/closing a window
Activating a window, i.e., window in focus
Resizing/moving/minimize/maximize a window class
Mouse button up/down
Scroll wheel up/down
Mouse move
Mouse-out/in
Keystroke pressed
Smalltalk IDE

15. DFlow
MetaUser InterfaceLow-Level
Opening/closing a window
Activating a window, i.e., window in focus
Resizing/moving/minimize/maximize a window class
Mouse button up/down
Scroll wheel up/down
Mouse move
Mouse-out/in
Keystroke pressed
DFLOW
Smalltalk IDE
Recorder Analyzer …
HTTP
DFLOW
Server

16. DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a method or a class
electing a method in the Finder UI
Starting a search in the Finder UI
Inspecting an object
Browsing a compiled method
Do-it/Print-it on a piece of code (e.g., workspace)
Stepping into/Stepping Over/Proceeding in a debugger
Run to selection in a debugger
Entering/exiting from an active debugger
Browsing full stack/stack trace in a debugger
Browsing hierarchy, implementors or senders of a class
Browsing the version control system
Browse versions of a method
Creating/removing a class
Adding/removing instance variables from a class
Adding/removing a method from a class
Automatically creating accessors for a class

17. DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a method or a class
electing a method in the Finder UI
Starting a search in the Finder UI
Inspecting an object
Browsing a compiled method
Do-it/Print-it on a piece of code (e.g., workspace)
Stepping into/Stepping Over/Proceeding in a debugger
Run to selection in a debugger
Entering/exiting from an active debugger
Browsing full stack/stack trace in a debugger
Browsing hierarchy, implementors or senders of a class
Browsing the version control system
Browse versions of a method
Creating/removing a class
Adding/removing instance variables from a class
Adding/removing a method from a class
Automatically creating accessors for a class
User Interface
Opening/closing a window
Activating a window, i.e., window in focus
Resizing/moving/minimize/maximize a window class

18. DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a method or a class
electing a method in the Finder UI
Starting a search in the Finder UI
Inspecting an object
Browsing a compiled method
Do-it/Print-it on a piece of code (e.g., workspace)
Stepping into/Stepping Over/Proceeding in a debugger
Run to selection in a debugger
Entering/exiting from an active debugger
Browsing full stack/stack trace in a debugger
Browsing hierarchy, implementors or senders of a class
Browsing the version control system
Browse versions of a method
Creating/removing a class
Adding/removing instance variables from a class
Adding/removing a method from a class
Automatically creating accessors for a class
User Interface
Low-Level
Opening/closing a window
Activating a window, i.e., window in focus
Resizing/moving/minimize/maximize a window class
Mouse button up/down
Scroll wheel up/down
Mouse move
Mouse-out/in
Keystroke pressed

19. Dataset
events
sessions
developers
rec. time
windows
738
18
197h13’ 54”
5,052,386
13,691

20. Research
Questions

21. Research
Questions
1) What is the time spent in
program understanding? What
about the other activities?

22. Research
Questions
1) What is the time spent in
program
about the other
2) How much time do developers
spend in fiddling with the user
interface of the IDE?

23. Research
Questions
1) What is the time spent in
program
about the other
2) How much time do developers
spend in fiddling with the
interface
3) What is the impact of the
fragmentation of the development
flow?

24. Interaction Histories
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
t
Search
starts
>RT
Search
ends
DOI
Active
Windows t
Window
activated
Out / In
in the IDE
Window
activated
W1 W2 W3 W2 W4
Method
saved
>RT >RT

25. Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
t
Search
starts
>RT
Search
ends
DOI
Active
Windows t
Window
activated
Out / In
in the IDE
Window
activated
W1 W2 W3 W2 W4
Method
saved
>RT >RT
No duration
Interaction Histories

26. >RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Interaction Histories

27. The Reaction Time (0.15 to 1.5 seconds)
>RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
How the Mind Works
S. Pinker
W. W. Norton, 1997Interaction Histories

28. >RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Interaction Histories

29. >RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Sprees and Activities
Mouse Keyboard
Activity
Interaction Histories

30. >RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3A2
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Sprees and Activities
Mouse Keyboard
Activity
Interaction Histories

31. >RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3A2
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Sprees and Activities
Mouse Keyboard
Activity
Interaction Histories
5,052,386
events
31,609
activities

32. >RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3
Editing
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Sprees and Activities
Mouse Keyboard
Activity
A2
Interaction Histories

33. >RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3
Editing
Understanding
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Sprees and Activities
Mouse Keyboard
Activity
A2
Interaction Histories

34. Time
Components
Editing
Understanding

35. Time
Components
Editing
Understanding
Navigation

36. Time
Components
Editing
Understanding
Navigation
User Interface

37. Time
Components
Editing
Understanding
Navigation
User Interface
Time Spent Outside the IDE

38. Results
5%
8%
14%
70%
4%
Editing
Understanding
Navigation
User Interface
Outside the IDE

39. Time
Components
Understanding
92%
1.5%
6.5%
Basic
Inspection
Mouse Drifting

40. Time
Components
Understanding
92%
1.5
6.5
Basic
Inspection
Mouse Drifting
A2

41. Research
Questions
RQ1
RQ2

42. Research
Questions
RQ1
RQ2
RQ3

43. Fragmentation:
Outside the IDE
vs.

44. Fragmentation:
Outside the IDE
vs.
Time spent
outside the IDE
Understanding
time

45. Fragmentation:
Outside the IDE
vs.
Time spent
outside the IDE
Understanding
time
PCC=0.46
p < 10-16

46. Fragmentation:
Outside the IDE
vs.
Time spent
outside the IDE
Number of times
outside the IDE
Understanding
time
Understanding
time
PCC=0.46
p < 10-16

47. Fragmentation:
Outside the IDE
vs.
Time spent
outside the IDE
Number of times
outside the IDE
Understanding
time
Understanding
time
PCC=0.46
p < 10-16
PCC=0.63
p < 10-16

48. Fragmentation:
Outside the IDE
vs.
Number of times
outside the IDE
User Interface
time

49. Fragmentation:
Outside the IDE
vs.
User Interface
time
PCC=0.65
p < 10-16
Number of times
outside the IDE

50. Fragmentation:
Outside the IDE
vs.
User Interface
time
PCC=0.65
p < 10-16
The Plague Doctor
Tue, 12:15 @ ICPC
Number of times
outside the IDE

51. write
read
navigate
user interface
program
understanding
Program understanding:
Challenge for the 1990s
In the Program Understanding Project at IBM's Re-search Division, work began in late 1986 on toolswhich could help programmers in two key areas: staticanalysis (reading the code) and dynamic analysis (run-ning the code). The work is reported in the companionpapers by Cleveland and by Pazel in this issue. Thehistory and background which motivated and whichled to the start of this research on tools to assistprogrammers in understanding existing program codeis reported here.
" If the poor workman hates his tools, the goodworkman hates poor tools. The work of theworkingman is, in a sense, defined by his tool-witness the way in which the tool is so often taken tosymbolize the worker:the tri-squarefor the carpenter,the trowelfor the mason, the transit for the surveyor,the camera for the photographer, the hammerfor thelaborer, and the sickle for the farmer.
"Working with defective or poorly designed tools,even the finest craftsman is reduced to producinginferior work, and is thereby reduced to being aninferior craftsman. No craftsman, ifhe aspires to thehighest work in his profession, will accept such tools;and no employer, if he appreciates the quality ofwork, will ask the craftsman to accept them. "I
Today a variety of motivators are causing corpora-tions to invest in software tools to increase softwareproductivity, including: (1) increased demand forsoftware, (2) limited supply of software engineers, (3)rising expectations of support from software engi-neers, and (4) reduced hardware costs.' A key moti-
by T. A. Corbi
vator for software tools in the 1990swill be the resultof having software evolve over the previous decadesfrom several-thousand-line, sequential programmingsystems into multimillion-line, multitasking "busi-ness-critical" systems. As the programming systemswritten in the 1960s and 1970s continue to mature,the focus for software tools will shift from tools thathelp develop new programming systems to tools thathelp us understand and enhance aging programmingsystems.
In the 1970s, the work of Belady and Lehman"?strongly suggested that all large programs wouldundergo significant change during the in-servicephase of their life cycle, regardless of the a prioriintentions of the organization. Clearly, they wereright. As an industry, we have continued to growand change our large software systems to:
• Remove defects
• Address new requirements
• Improve design and/or performance
• Interface to new programs
• Adjust to changes in data structures or formats• Exploit new hardware and software features
As we extended the lifetimes of our systems bycontinuing to modify and enhance them, we also
e Copyright 1989by International BusinessMachines Corporation.Copying in printed form for private use is permitted withoutpayment of royalty provided that (I) each reproduction is donewithout alteration and (2)the Journalreference and IBM copyrightnotice are included on the first page. The title and abstract, but noother portions, of this paper may be copied or distributed royaltyfree without further permission by computer-based and otherinformation-service systems. Permission to republish any otherportion of this paper must be obtained from the Editor.
…up to 50%

52. write
read
navigate
user interface
program
understanding
Program understanding:
Challenge for the 1990s
In the Program Understanding Project at IBM's Re-search Division, work began in late 1986 on toolswhich could help programmers in two key areas: staticanalysis (reading the code) and dynamic analysis (run-ning the code). The work is reported in the companionpapers by Cleveland and by Pazel in this issue. Thehistory and background which motivated and whichled to the start of this research on tools to assistprogrammers in understanding existing program codeis reported here.
" If the poor workman hates his tools, the goodworkman hates poor tools. The work of theworkingman is, in a sense, defined by his tool-witness the way in which the tool is so often taken tosymbolize the worker:the tri-squarefor the carpenter,the trowelfor the mason, the transit for the surveyor,the camera for the photographer, the hammerfor thelaborer, and the sickle for the farmer.
"Working with defective or poorly designed tools,even the finest craftsman is reduced to producinginferior work, and is thereby reduced to being aninferior craftsman. No craftsman, ifhe aspires to thehighest work in his profession, will accept such tools;and no employer, if he appreciates the quality ofwork, will ask the craftsman to accept them. "I
Today a variety of motivators are causing corpora-tions to invest in software tools to increase softwareproductivity, including: (1) increased demand forsoftware, (2) limited supply of software engineers, (3)rising expectations of support from software engi-neers, and (4) reduced hardware costs.' A key moti-
by T. A. Corbi
vator for software tools in the 1990swill be the resultof having software evolve over the previous decadesfrom several-thousand-line, sequential programmingsystems into multimillion-line, multitasking "busi-ness-critical" systems. As the programming systemswritten in the 1960s and 1970s continue to mature,the focus for software tools will shift from tools thathelp develop new programming systems to tools thathelp us understand and enhance aging programmingsystems.
In the 1970s, the work of Belady and Lehman"?strongly suggested that all large programs wouldundergo significant change during the in-servicephase of their life cycle, regardless of the a prioriintentions of the organization. Clearly, they wereright. As an industry, we have continued to growand change our large software systems to:
• Remove defects
• Address new requirements
• Improve design and/or performance
• Interface to new programs
• Adjust to changes in data structures or formats• Exploit new hardware and software features
As we extended the lifetimes of our systems bycontinuing to modify and enhance them, we also
e Copyright 1989by International BusinessMachines Corporation.Copying in printed form for private use is permitted withoutpayment of royalty provided that (I) each reproduction is donewithout alteration and (2)the Journalreference and IBM copyrightnotice are included on the first page. The title and abstract, but noother portions, of this paper may be copied or distributed royaltyfree without further permission by computer-based and otherinformation-service systems. Permission to republish any otherportion of this paper must be obtained from the Editor.
…up to 50%

53. “When developers stare at their screens
without any movement: Don’t worry,
they’re ok, leave them alone.”
Roberto Minelli, Andrea Mocci, Michele Lanza
REVEAL @ Faculty of Informatics — University of Lugano, Switzerland
@robertominelli