I Know What You Did Last SummerAn Investigation of How Developers Spend Their Time

Roberto Minelli, Andrea Mocci, Michele Lanza REVEAL @ Faculty of Informatics — University of Lugano, Switzerland

@robertominelli

write

write

read

write

read

navigate

write

read

navigate

user interface

write

read

navigate

user interface

program understanding

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 trowel for the mason, the transit for the surveyor,the camera for the photographer, the hammer for 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, if he 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-

294 CORBI

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 featuresAs we extended the lifetimes of our systems bycontinuing to modify and enhance them, we alsoe 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 IBMcopyrightnotice 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.

IBM SYSTEMS JOURNAL, VOL 28, NO 2, 1989

…up to 50%

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 trowel for the mason, the transit for the surveyor,the camera for the photographer, the hammer for 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, if he 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-

294 CORBI

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 featuresAs we extended the lifetimes of our systems bycontinuing to modify and enhance them, we alsoe 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 IBMcopyrightnotice 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.

IBM SYSTEMS JOURNAL, VOL 28, NO 2, 1989

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 trowel for the mason, the transit for the surveyor,the camera for the photographer, the hammer for 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, if he 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-

294 CORBI

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 featuresAs we extended the lifetimes of our systems bycontinuing to modify and enhance them, we alsoe 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 IBMcopyrightnotice 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.

IBM SYSTEMS JOURNAL, VOL 28, NO 2, 1989

Does this myth hold?

The Pharo IDE

Enter some B$ about Pharò

The Pharo IDE: Debugger

Enter some B$ about Pharò

Enter some B$ about Pharò

The Pharo IDE: Code Browser

IDE Interaction Data

IDE developer

interactions

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

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

DFlow

MetaOpening 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

DFlow

MetaOpening 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

DFlow

MetaOpening 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

Dataset

events

sessionsdevelopersrec. time

windows

73818

197h13’ 54”5,052,386

13,691

Research Questions

Research Questions

1)  What is the time spent in program understanding? What about the other activities?

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?

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?

Interaction Histories

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

t

Searchstarts

>RT

Searchends

DOI

ActiveWindows t

Windowactivated

Out / Inin the IDE

Windowactivated

W1 W2 W3 W2 W4

Methodsaved

>RT >RT

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

t

Searchstarts

>RT

Searchends

DOI

ActiveWindows t

Windowactivated

Out / Inin the IDE

Windowactivated

W1 W2 W3 W2 W4

Methodsaved

>RT >RT

No duration

Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Interaction Histories

The Reaction Time (0.15 to 1.5 seconds)>RT

Windows W1 W2 W

Methodsaved

>RT >RT

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

How the Mind Works S. Pinker

W. W. Norton, 1997Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

MS1 MS2 KSKS1 KS2 KS3

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Sprees and ActivitiesMouse KeyboardActivity

Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

MS1 MS2 KSKS1 KS2 KS3

A1 A3A2

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Sprees and ActivitiesMouse KeyboardActivity

Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

MS1 MS2 KSKS1 KS2 KS3

A1 A3A2

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Sprees and ActivitiesMouse KeyboardActivity

Interaction Histories

5,052,386 events

31,609 activities

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

MS1 MS2 KSKS1 KS2 KS3

A1 A3Editing

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Sprees and ActivitiesMouse KeyboardActivity

A2

Interaction Histories

>RT

Windows W1 W2 W

Methodsaved

>RT >RT

MS1 MS2 KSKS1 KS2 KS3

A1 A3Editing

Understanding

EventsMouse KeyboardWindow Meta

WindowsWorkspace Code BrowserFinder

Sprees and ActivitiesMouse KeyboardActivity

A2

Interaction Histories

Time Components

Editing

Understanding

Time Components

Editing

Understanding

Navigation

Time Components

Editing

Understanding

Navigation

User Interface

Time Components

Editing

Understanding

Navigation

User Interface

Time Spent Outside the IDE

Results

5%

8%

14%

70%

4%

Editing

Understanding

Navigation

User Interface

Outside the IDE

Time Components

Understanding

92%

1.5%

6.5%

Basic

Inspection

Mouse Drifting

Time Components

Understanding

92%

1.5

6.5

Basic

Inspection

Mouse Drifting

A2

Research Questions

RQ1

RQ2

Research Questions

RQ1

RQ2

RQ3

Fragmentation: Outside the IDE

vs.

Fragmentation: Outside the IDE

vs.

Time spent outside the IDE

Understanding time

Fragmentation: Outside the IDE

vs.

Time spent outside the IDE

Understanding time

PCC=0.46 p < 10-16

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

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

Fragmentation: Outside the IDE

vs.

Number of times outside the IDE

User Interface time

Fragmentation: Outside the IDE

vs.

User Interface time

PCC=0.65 p < 10-16

Number of times outside the IDE

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

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 trowel for the mason, the transit for the surveyor,the camera for the photographer, the hammer for 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, if he 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-

294 CORBI

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 featuresAs we extended the lifetimes of our systems bycontinuing to modify and enhance them, we alsoe 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 IBMcopyrightnotice 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.

IBM SYSTEMS JOURNAL, VOL 28, NO 2, 1989

…up to 50%

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 trowel for the mason, the transit for the surveyor,the camera for the photographer, the hammer for 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, if he 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-

294 CORBI

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 featuresAs we extended the lifetimes of our systems bycontinuing to modify and enhance them, we alsoe 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 IBMcopyrightnotice 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.

IBM SYSTEMS JOURNAL, VOL 28, NO 2, 1989

…up to 50%

“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