Getting to Flow in Software Development (ASWEC 2014 Keynote)

842 views
711 views

Published on

Humans are amazing at processing information. It is a good thing that they are because software development projects generate a tremendous amount of information of various forms from predominantly natural language documents like requirements to blended natural language and structured artifacts like issues to predominantly structured source and test code. For some time, the amount of information produced daily in a large software development has exceeded a human’s ability to process that information. Instead of producing tools that allow a software developer to focus on information pertinent to a task, too many tools have been built that focus solely on producing as much information as possible. In this talk, I will discuss interaction styles for tools that may bring us closer to keeping a developer in the flow of a task. By improving flow, we can enable developers to work smarter, work better and have more fun.

Published in: Software, Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
842
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
15
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Getting to Flow in Software Development (ASWEC 2014 Keynote)

  1. 1. getting to flow in software development Gail C. Murphy
 
 University of British Columbia
 Tasktop Technologies Incorporated
  2. 2. “software is eating the world” Marc Andreesen
  3. 3. premise
 … lots of software to build should be fun to build it
  4. 4. hypothesis … tools and interfaces that support flow enable building 
 
 more software 
 with more fun
  5. 5. what is flow? Mihaly Csikszentmihalyi
 single-minded immersion
 
 clear set of goals and progress
 clear and immediate feedback
 balance of challenges to skills
  6. 6. 21.9%50.4%53.2% complete tasks or goals getting into a “flow” without many “context switches” and no or few interruptions and distractions no meetings top 3 reasons for
 productive day (379 devs) [Meyer, Fritz, Murphy & Zimmermann, under submission]
  7. 7. Actvities and Task Switches (Session 1) Time [minutes] Subject 0 30 60 90 120 150 180 T3 T2 T1 S4 S3 S2 S1 R4 R3 R2 R1 ● ● ● ● ● ● ●● ●●●● ● ● ● ● ● ● ●●●●● ● ● ●●● ●●● ●● ● 51 activity switches 10 task switches, 3 distinct tasks ● ● ●● ● ●●●● ● ●● ● ● ●● ●● ● ●● ●●● ●●●● ● ● ●● ● ● ● ●●● ● ● ● ●●● ● ●● ● ● ● ● ● ● ● ●● ● ● ● ● ● ●●●● ● ● ●● ● ●●●● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ●● ● ● ● ● ●● ● ● ● ● ● ●●● ● ● ● ● ● ● ● ●● ● ● ●● ● 166 activity switches 36 task switches, 3 distinct tasks ● ●●●● ● ● ● ●● ●●● ● ● ● ● ● ● ● ● ● ● ●● ● ●● ● ●●● ● ● ● ● ●●● ● ●● ● ● ● ● ● ● ● ● ●●●● ● ● ●●● ● ● ●● ● ● ●●● ●●● ●●● ●●●●● ● ● ●●●●●●●● ● ●●● ● ● ●● ●● ● ●● ● ●● ● ● ● ● ● ● ● ●● ● ●●●● ●●● ● ●● ● ●●●●●● ● ●● ● ●●● ● ● ● 230 activity switches 79 task switches, 4 distinct tasks ●● ●● ● ●● ● ● ●●● ● ●● ●●●●● ●● ●● ● ●●●●● ●● ● ●●●● ● ● ● ● ●● ●● ● ●● ● ● ● 85 activity switches 13 task switches, 4 distinct tasks ● ●● ●● ●● ● ● ● ●●● ●● ●●●● ● ● ● ●●● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ●● ● ● 59 activity switches 20 task switches, 5 distinct tasks ● ● ●●● ● ● ●●●● ●●● ● ● ● ● ● ● ● ●●● ●●● ● ● ● ● ● 88 activity switches 17 task switches, 5 distinct tasks ● ● ●●● ●●●●●●● ●● ●● ● ●●●● ● ● ● ● ●●●●● ● ● ● ●● ● ● ● ● ●● ●● ●●●●●●● ●● ● ●● ● ● ●●● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ●● ●● ●●● ●● ● ● ● ● ● ●●● ●● ● ● ● ●●● ● ● 148 activity switches 27 task switches, 4 distinct tasks ● ●●● ●● ●● ● ● ● ● ●● ●●●●● ●●● ●● ● ●●●● ●●● ● ● ● ●●● ● ●● ●● ● 108 activity switches 16 task switches, 5 distinct tasks ● ● ● ● ● ● ●● ● ●● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● 66 activity switches 25 task switches 4 distinct tasks ● ● ● ● ● ●●● ● ● ● ● ● ●●● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ●● ●● ● ● 102 activity switches 61 task switches 6 distinct tasks ● ● ● ●●● ● ●●●●●●●●●● ● ●● ● ● ● ● ● ● ● ● ●●●●●●● ● ● ●●●●● ●●●● ● ● ● ●●● ● ● ●● ●● ●● 96 activity switches 28 task switches, 4 distinct tasks ● ● ● ● ● ● Dev:VC Dev:Debug Dev:Code Dev:Review Dev:TestApp Dev:Other BrowsingRel BrowsingUnrel MeetInformal MeetPlanned Email Planning ReadWriteDoc Other constant switching [Meyer, Fritz, Murphy & Zimmermann, under submission]
  8. 8. ok? development tools and interfaces already do a great job at supporting flow
  9. 9. jHotDraw
  10. 10. add code in several places
  11. 11. bug
  12. 12. mismatch #1
 flat information space

  13. 13. mismatch #2
 multiple disconnected information
  14. 14. mismatch #3: information overload
  15. 15. mismatch #4: clickitis over cognition
  16. 16. mismatches #1: flat information space #2: multiple disconnected information spaces #3: information overload #4: clickitis over cognition goal
  17. 17. an example of how it could be approaches and tools that address the mismatches
  18. 18. [Ko and Myers, 2008]
  19. 19. techniques for
 improved flow • task context • recommendations • dialog • summarization
  20. 20. technique #1 of 4:
 task context • parts and relationships of artifacts relevant to developer as they work on a task • different approximations • e.g., commits • e.g., interaction history
 (Eclipse Mylyn) [Kersten & Murphy, 2006]
  21. 21. task context in Mylyn tasks [Kersten & Murphy, 2006]
  22. 22. if we have task context… • have a mapping between “intent” and parts of artifacts • can use as a concept mapping • can use as basis for recommending artifacts to look at • could use to analyze defects based on ‘intent” • reduce information space shown to the developer • share work
  23. 23. achieving flow with task context… • capture without requiring work on the part of the developer • challenge: how to get broader intent? • challenge: how to get all parts of artefacts worked on or looked at? • challenge: how to infer task switches automatically?
  24. 24. technique #2 of 4:
 recommendations • suggest parts of current or past information spaces that might be helpful for current work • e.g., text similarity on previously solved bugs [Čubranić & Murphy 2003] • e.g., where others have navigated from a given point [DeLine et. al. 2005]
  25. 25. recommendations in Hipikat [Čubranić & Murphy, 2003]
  26. 26. if we have recommendations… • can eliminate low-level searching and navigating • can reduce incorrect paths followed • can help if developer is stuck • can provide information a developer might miss
  27. 27. achieving flow with recommendations… • challenge: appropriate effective user interface delivery
 
 
 • challenge: what are sufficient precision and recall for various tasks • challenge: explaining recommendations
  28. 28. technique #3 of 4: dialog • make units of discourse between developer and interface dialog • task-specific • e.g., Whyline for debugging [Ko & Myers 2004 & 2008] • e.g., Ferret for code navigation [de Alwis & Murphy 2008]
  29. 29. Ferret navigation Whyline debugging
  30. 30. if we have dialog… • can eliminate low-level searching and navigating • can reduce incorrect paths followed • may be able to make it easier for broader range of people to program effectively
  31. 31. achieving flow with dialog… • challenge: can we make general approaches for broad task categories? • challenge: what are appropriate user interaction flows for dialog? • challenge: what if a question isn’t presented that needs to be asked?
  32. 32. technique #4 of 4: summarization • present abstracted form of information • extractive or abstractive • e.g., bugs [Rastkar & Murphy, 2010, 2013] • e.g., code [Moreno 2013]
  33. 33. bug summarization Epic StoryStory TaskTask extracted
 summaryuse machine learning to learn and extract appropriate sentences [Rastkar & Murphy, 2010 &2012]
  34. 34. if we have summarization… • developer can make more informed decisions as timely effective access to information • can look for similarities and trends at different level of abstraction • keep developer focused on task by eliminating cognitive switches
  35. 35. achieving flow with summarization • challenge: what to summarize when? • challenge: how much intent needs to be known to summarize effectively? • challenge: how accurate must a summary be not to be mis-leading?
  36. 36. interaction for flow 1. flat information space 2. multiple disconnected information spaces 3. information overload 4. clickitis over cognition mismatches interaction types • task context • recommendation • dialog • summarization
  37. 37. what should the programming tools of the future look like? is it enough in research to produce approaches that fill information
 spaces?
  38. 38. john anvik elisa baniassad wesley coelho davor cubranic brian de alwis rob elves thomas fritz reid holmes rahul jiresal mik kersten shawn minto e murphy-hill jingwen ou martin robillard sarah rastkar nick sawadsky david shepherd ducky sherwood annie ying robert walker and many others!
  39. 39. Actvities and Task Switches (Session 1) Time [minutes] Subject 0 30 60 90 120 150 180 T3 T2 T1 S4 S3 S2 S1 R4 R3 R2 R1 ● ● ● ● ● ● ●● ●●●● ● ● ● ● ● ● ●●●●● ● ● ●●● ●●● ●● ● 51 activity switches 10 task switches, 3 distinct tasks ● ● ●● ● ●●●● ● ●● ● ● ●● ●● ● ●● ●●● ●●●● ● ● ●● ● ● ● ●●● ● ● ● ●●● ● ●● ● ● ● ● ● ● ● ●● ● ● ● ● ● ●●●● ● ● ●● ● ●●●● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ●● ● ● ● ● ●● ● ● ● ● ● ●●● ● ● ● ● ● ● ● ●● ● ● ●● ● 166 activity switches 36 task switches, 3 distinct tasks ● ●●●● ● ● ● ●● ●●● ● ● ● ● ● ● ● ● ● ● ●● ● ●● ● ●●● ● ● ● ● ●●● ● ●● ● ● ● ● ● ● ● ● ●●●● ● ● ●●● ● ● ●● ● ● ●●● ●●● ●●● ●●●●● ● ● ●●●●●●●● ● ●●● ● ● ●●●● ● ●● ● ●● ● ● ● ● ● ● ● ●● ● ●●●● ●●● ● ●● ● ●●●●●● ● ●● ● ●●● ● ● ● 230 activity switches 79 task switches, 4 distinct tasks ●● ●● ● ●● ● ● ●●● ● ●● ●●●●● ●● ●● ● ●●●●● ●● ● ●●●● ● ● ● ● ●● ●● ● ●● ● ● ● 85 activity switches 13 task switches, 4 distinct tasks ● ●● ●● ●● ● ● ● ●●● ●● ●●●● ● ● ● ●●● ● ● ● ● ● ● ● ●●● ● ● ● ● ● ●● ● ● 59 activity switches 20 task switches, 5 distinct tasks ● ● ●●● ● ● ●●●● ●●● ● ● ● ● ● ● ● ●●● ●●● ● ● ● ● ● 88 activity switches 17 task switches, 5 distinct tasks ● ● ●●● ●●●●●●● ●● ●● ● ●●●● ● ● ● ● ●●●●● ● ● ● ●● ● ● ● ● ●● ●● ●●●●●●● ●● ● ●● ● ● ●●● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ●● ●● ●●● ●● ● ● ● ● ● ●●● ●● ● ● ● ●●● ● ● 148 activity switches 27 task switches, 4 distinct tasks ● ●●●●● ●● ● ● ● ● ●● ●●●●● ●●● ●● ● ●●●● ●●● ● ● ● ●●● ● ●● ●● ● 108 activity switches 16 task switches, 5 distinct tasks ● ● ● ● ● ● ●● ● ●● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● 66 activity switches 25 task switches 4 distinct tasks ● ● ● ●● ●●● ● ● ● ● ● ●●● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ●● ●● ● ● 102 activity switches 61 task switches 6 distinct tasks ● ● ● ●●● ● ●●●●●●●●●● ● ●● ● ● ● ● ● ● ● ● ●●●●●●● ● ● ●●●●● ●●●● ● ● ● ●●● ● ● ●● ●● ●● 96 activity switches 28 task switches, 4 distinct tasks ● ● ● ● ● ● Dev:VC Dev:Debug Dev:Code Dev:Review Dev:TestApp Dev:Other BrowsingRel BrowsingUnrel MeetInformal MeetPlanned Email Planning ReadWriteDoc Other software is 
 eating the
 world interfaces need to support flow interaction styles that might improve flow • task context • recommendation • dialog • summarization what might programming environments look like to make programming more fun and more inclusive Gail C. Murphy @gail_murphy

×