Information Needs in Collocated Software Development Teams A.J. Ko, R. DeLine, G. Venolia

1. Information Needsin Collocated Software Development TeamsA.J. Ko, R. DeLine, G. Venolia Presented by : IlhanAkbas BilalOrhan

2. Introduction • The starting point is the question: • What information developers look for and why? • With an answer to this question we might better understand what tools, processes or practices could help developers.

3. Introduction • To answer the following questions a 2 month field study has been conducted with Microsoft software developers. (a total of 17 groups, 21 questions and 25 hours of interview) • What information software developers‘ seek? • Where do they find this information? • What inhibits the acquisition of such information?

4. Context and Author(s) • The study is done in MSR with Microsoft developers by an expert team. • Andrew J. Ko :First author, made internship in summer2006 at Microsoft research, CMU PhD student. • R. Deline : Senior Researcher (group manager) in Human Interaction in Programming (HIP). • G. D Venolia : A user interface architect in HIP.

5. Context cont. • “The HIP group is creating new software development tools based on the obvious observation that software development is done by people working together.” • HIP group does field studies hanging out with developers usually. So the study shown on this paper is done by experts and with people knowing each other.

6. Presentation Overview • Introduction • Context and Authors • Related Work • Method • Task Structure • Questions ?(Information Need ) • Results (Quantifying Information Needs ) • Discussions • Conclusion

7. Related Work • Software development has a social nature. • Developers spent half the time interacting with coworkers, mainly to maintain awareness.[3,13] • Local mobility facilitates awareness. [6, 15] • Developers also communicate to obtain knowledge [3, 7, 10, 11] • A consequence of information needs is time fragmentation, which is largely due to interruptions. [5,12,13] • Dependencies are a central factor in software development work. [3,11]

8. Method • Selecting developers from corporate research and conducting 90 minute observation sessions. A total of 17 developers. • Each session is done by one observer recording notes about the developers’ work. • The observers have the same programming background and much of the developers thought a loud.

9. Task Structure • Logged activities are partitioned into tasks, as: Writing/submitting code, reproducing failures, triaging bugs, reasoning about design, maintaining awareness and non-work. • Tasks switches are shown with following endings. If the switch is voluntary then it is interruption, otherwise blocked.

10. Task StructureSamples

11. Presentation Overview • Introduction • Context and Authors • Related Work • Method • Task Structure • Questions[1-7]? (Information Need ) • Results (Quantifying Information Needs ) • Discussions • Conclusion

12. Questions? - 1 • Writing Code • c1. What data structures or functions can be used to implement this behavior? • c2. How do I use this data structure of function? • c3. How can I coordinate this with this other data structure or function?

13. Questions? - 2 • Submitting a change • s1. Did I make any mistakes in my new code? • s2. Did I follow my team’s conventions? • s3. Which changes are part of this submission?

14. Questions? - 3 • Triaging Bugs • b1. Is this a legitimate problem? • b2. How difficult will this problem be to fix? • b3. Is it worth fixing?

15. Questions? - 4 • Reproducing Failures • r1. What does the failure look like? • r2. In what situations does this failure occur?

16. Questions? - 5 • Understanding Behavior • u1. What code could have caused this behavior? • u2. What’s statically related to this code? • u3. What code caused this program state?

17. Questions? - 6 • Reasoning about Design • d1. What is the purpose of this code? • d2. What is the program is supposed to do? • d3. Why was this code implemented this way? • d4. What are the implications of this change?

18. Questions? - 7 • Maintaining awareness • a1. How have resources I depend on changed? • a2. What have my coworkers been doing? • a3. What information was relevant to my task?

19. Quantifying results • The following figure will show the trends for each question. • Search Times, Frequency and outcome of the searches and frequency of source which come from 25 hour observation log. • The agreement of developers about the information types being important, unavailable, inaccurate from a survey of 45 developers

20. Quantifying results The most frequently sought and acquired information.

21. Quantifying results The most often deferred information.

22. Quantifying results Information took longest to acquire, based on median or max.

23. Quantifying results The most common sources of information are in bold. Bug reports and co workers

24. Quantifying results • The survey also shows some trends like: • More frequent ones are rated as more important • More deferred as more unavailable. • The knowledge about design, behavior and triage is more questionable. • Coworker awareness is not important. • Difficult to obtain the knowledge about the implications of a change.

25. Presentation Overview • Introduction • Context and Authors • Related Work • Method • Task Structure • Questions ?(Information Need ) • Results (Quantifying Information Needs ) • Discussions • Conclusion

26. Discussions • Awareness was one of the most sought and found types of information consistent with prior work. • The design knowledge was primarily stored in the minds of developers so they rely on each other and blockings occur. • Many of the information needs are satisfied by consulting the coworkers. • Automate the acquisition of information. Use standards, so the information may be transformed and passed between tools. • There are description languages but are they cost efficient? A demand-driven approach to record design knowledge might succeed over a eager “record everything approach”.

27. Discussions • Two of the developers had design notations(e.g. prototype) they can refer, so they were not blocked. • Prototypes are valuable sources of design knowledge for software design and implementation.

28. Conclusion • The goal of this study was to identify the information needs of developers and characterize the role of these needs. • Study shows the necessity and trends for innovation in tools, processes and notations. • Also revealed how the distributed nature of design knowledge lead to intense need for awareness and communication.

29. Pros. • The study was performed in the context of developers’ work. • There were 2 independent observers. • Two of the authors are experts for this type of field studies. • The work is conducted in the corporate with the availability of the company itself.

30. Cons. • Developers also spent time to respond to observers. (bias) • Some of the information searches are unobservable, because the nature of the search or limited time of the observation. • Only the developers are studied, it can be extended to testers and architects. (future work)