View
56
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended