1. Collaborative Software Engineering – Awareness and Concurrency Agam

2. Outline Introduction to CSE Brief overview of five recent papers Synthesis with in-class discussion

3. Introduction to CSE Seamless, fine-grained, real-time collaboration between geographically distributed software engineers Example: Pair programming Refactoring Working on any part of the software design/analysis process as a distributed team

4. Introduction to CSE (contd.) Research Areas in CSE

5. Introduction to CSE (contd.) Design space of CSE tools lies between two extremes (optimistic, pessimistic)

6. Brief overview of papers “Interruptions on Software Teams: A Comparison of Paired and Solo Programmers” J. Chong, R. Siino CSCW 2006 “CVS Integration with Notification and Chat: Lightweight Software Team Collaboration” G. Fitzpatrick, P. Marshall, A. Phillips CSCW 2006

7. Brief overview of papers (contd.) “A User Evaluation of Synchronous Collaborative Software Engineering Tools” C. Cook, W. Irvin, N. Churcher APSEC 2005 “Towards Synchronous Collaborative Software Engineering” C. Cook, N. Churcher, W. Irvin APSEC 2004 “Modelling and Measuring Collaborative Software Engineering” C. Cook, N. Churcher ACSC 2005

8. “Lightweight Software Team collaboration …” Communication Mediated Informal Idea: public awareness of CVS contents as a means of communication Currently being performed (in a weak sense) by mailing lists

9. “Lightweight Software Team collaboration …” (contd.) Most prevalent form of CSE – version control !! Idea – combine this with informal communication Result – mediated communication

10. “Lightweight Software Team collaboration …” (contd.) Visualization of CVS a good idea ‘tickertape’ mechanism used to broadcast recent CVS activity to team “publish/subscrive” system displays Made users aware of “manipulation of project artifacts” Studied interaction/discussion arising from

11. “Lightweight Software Team collaboration …” (contd.) Results of study Stimulated developer discussion Promoted ‘awareness’ CVS log had better context, more info Helps document “flow” (commentary !)

12. “Lightweight Software Team collaboration …” (contd.) Results of study (contd.) ‘commit’ operation – public act (as it should be, marking transition of code from private workspace to public workspace) – Awareness ! Knowing that other developers are ‘tracking’ makes a difference – interruptibility management !

13. “Modelling and Measuring CSE …” CSE demands a little more than typical CSCW (E.g. shared whiteboards) Longer lifetimes Higher conflict resolution cost More complexity Currently rely on “social protocols”

14. “Modelling and Measuring CSE …” (contd.) CAISE architecture Server based Semantic model maintained Requires parsers/analysers Events – input/change/feedback Supports visualization

15. “Modelling and Measuring CSE …” (contd.) Editor Panel User Tree Client Panel

16. “Modelling and Measuring CSE …” (contd.)

17. Objectives Builds at different temporal granularities Fine-grained integrity Semantic-based awareness and feedback Private work and re-integration

18. “Modelling and Measuring CSE …” (contd.) CAISE and CSE Provides Taskwork-oriented features (as do traditional systems) But also -- Teamwork-oriented features Different modes reflecting different approaches to conflict resolution

19. “Modelling and Measuring CSE …” (contd.) Private (traditional) mode – similar to cvs Independent – simultaneos work (CAISE monitors semantic relationship) Melee – active conflict resolution by developers (communicate using out- of-band channel) WYSIWIS – “tour of the code”

20. “Modelling and Measuring CSE …” (contd.) Server allows awareness of Code dependencies Developer relationships Visualization – see changes to code base over time

21. “User evaluation of synchronous CSE …” (contd.) User Study Two modes Conventional Collaborative Two types of tasks Inter-file Intra-file Measured task-completion times

22. “User evaluation of synchronous CSE …” (contd.) Results Collaborative mode twice as fast Subjective survey results approved (tools rated 14-15 on a scale of 1-20)

23. “Interruptions on Software Teams …” Studied interaction in the workplace, more specifically knowledge-intensive work Developers take breaks from work Social nature Functional nature Frequently interrupt each other

24. “Interruptions on Software Teams …” (contd.) User study of two situations Programmers working as a “pair” (co- located) Programmers working “solo” (remotely)

25. “Interruptions on Software Teams …” (contd.) Observations Interruptions – both functional + social for solo, largely functional for pair Pair was harder to interrupt ‘interruptibility’ for pair easier to assess Resumption of task/switching tasks faster for pair

26. “Interruptions on Software Teams …” (contd.) Observations Awareness of interruptiblity => Can handle interruptions better ! ‘Team pair’ – partner helps maintains state

27. “Interruptions on Software Teams …” (contd.) Conclusions Design Implication – make programmers ‘aware’ of multiple tasks to get same benefit for remote collaboration Actively maintain context

28. Awareness and Concurrency Awareness Know what other users are doing Helps avoid major conflicts Awareness of interruptibility Similar to mailing lists Conflict Resolution Concurrency Control Helps avoid developers making conflicting changes

29. Awareness and Concurrency (contd.) Conclusion Explored three different areas Issue of ‘collaboration’ in software engineering Augmenting CVS with simple tool – trasforms developer relationships CAISE – awareness of relationships - > conflict resolution Awareness related to interruptibility

30. Thank you ! (Questions ?)