Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
I Know What You Did Last Summer
An Investigation of How Developers Spend Their Time
Roberto Minelli, Andrea Mocci, Michele...
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 Und...
write
read
navigate
user interface
program
understanding
workman hates his tools, the good
hates poor tools. The work of t...
write
read
navigate
user interface
program
understanding
workman hates his tools, the good
hates poor tools. The work of t...
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/mini...
DFlow
MetaUser InterfaceLow-Level
Opening/closing a window
Activating a window, i.e., window in focus
Resizing/moving/mini...
DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a met...
DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a met...
DFlow
Meta
Opening a Finder UI
Selecting a package, method, or class in the code browser
Opening a system browser on a met...
Dataset
events
sessions
developers
rec. time
windows
738
18
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...
Research
Questions
1)  What is the time spent in
program
about the other
2)  How much time do developers
spend in fiddling...
Interaction Histories
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
t
Search
starts
>RT
Search
e...
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
t
Search
starts
>RT
Search
ends
DOI
Active
Windows...
>RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Interaction Histories
The Reaction Time (0.15 to 1.5 seconds)
>RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code...
>RT
Windows W1 W2
>RT >RT
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Interaction Histories
>RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Finder
Spree...
>RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3A2
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Find...
>RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3A2
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browser
Find...
>RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3
Editing
Events
Mouse Keyboard
Window Meta
Windows
Workspace Code Browse...
>RT
Windows W1 W2
>RT >RT
MS1 MS2KS1 KS2 KS3
A1 A3
Editing
Understanding
Events
Mouse Keyboard
Window Meta
Windows
Workspa...
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
Understan...
Fragmentation:
Outside the IDE
vs.
Time spent
outside the IDE
Number of times
outside the IDE
Understanding
time
Understan...
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 ti...
write
read
navigate
user interface
program
understanding
Program understanding:
Challenge for the 1990s
In the Program Und...
write
read
navigate
user interface
program
understanding
Program understanding:
Challenge for the 1990s
In the Program Und...
“When developers stare at their screens
without any movement: Don’t worry,
they’re ok, leave them alone.”
Roberto Minelli,...
Prochain SlideShare
Chargement dans…5
×
Prochain SlideShare
ICPC 2015 - Welcome from the chairs
Suivant
Télécharger pour lire hors ligne et voir en mode plein écran

0

Partager

Télécharger pour lire hors ligne

I Know What You Did Last Summer – An Investigation of How Developers Spend Their Time [ICPC2015]

Télécharger pour lire hors ligne

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.

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir
  • Soyez le premier à aimer ceci

I Know What You Did Last Summer – An Investigation of How Developers Spend Their Time [ICPC2015]

  1. 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. 2. write
  3. 3. write read
  4. 4. write read navigate
  5. 5. write read navigate user interface
  6. 6. write read navigate user interface program understanding
  7. 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. 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. 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. 10. The Pharo IDE Enter some B$ about Pharò
  11. 11. The Pharo IDE: Debugger Enter some B$ about Pharò
  12. 12. Enter some B$ about Pharò The Pharo IDE: Code Browser
  13. 13. IDE Interaction Data IDE developer interactions
  14. 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. 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. 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. 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. 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. 19. Dataset events sessions developers rec. time windows 738 18 197h13’ 54” 5,052,386 13,691
  20. 20. Research Questions
  21. 21. Research Questions 1)  What is the time spent in program understanding? What about the other activities?
  22. 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. 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. 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. 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. 26. >RT Windows W1 W2 >RT >RT Events Mouse Keyboard Window Meta Windows Workspace Code Browser Finder Interaction Histories
  27. 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. 28. >RT Windows W1 W2 >RT >RT Events Mouse Keyboard Window Meta Windows Workspace Code Browser Finder Interaction Histories
  29. 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. 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. 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. 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. 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. 34. Time Components Editing Understanding
  35. 35. Time Components Editing Understanding Navigation
  36. 36. Time Components Editing Understanding Navigation User Interface
  37. 37. Time Components Editing Understanding Navigation User Interface Time Spent Outside the IDE
  38. 38. Results 5% 8% 14% 70% 4% Editing Understanding Navigation User Interface Outside the IDE
  39. 39. Time Components Understanding 92% 1.5% 6.5% Basic Inspection Mouse Drifting
  40. 40. Time Components Understanding 92% 1.5 6.5 Basic Inspection Mouse Drifting A2
  41. 41. Research Questions RQ1 RQ2
  42. 42. Research Questions RQ1 RQ2 RQ3
  43. 43. Fragmentation: Outside the IDE vs.
  44. 44. Fragmentation: Outside the IDE vs. Time spent outside the IDE Understanding time
  45. 45. Fragmentation: Outside the IDE vs. Time spent outside the IDE Understanding time PCC=0.46 p < 10-16
  46. 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. 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. 48. Fragmentation: Outside the IDE vs. Number of times outside the IDE User Interface time
  49. 49. Fragmentation: Outside the IDE vs. User Interface time PCC=0.65 p < 10-16 Number of times outside the IDE
  50. 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. 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. 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. 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

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.

Vues

Nombre de vues

467

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

2

Actions

Téléchargements

4

Partages

0

Commentaires

0

Mentions J'aime

0

×