Collaborative Software Engineering – Awareness and Concurrency Agam

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

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

Introduction to CSE (contd.) Research Areas in CSE

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

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

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

“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

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

“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

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

“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 !

“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”

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

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

“Modelling and Measuring CSE …” (contd.)

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

“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

“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”

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

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

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

“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

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

“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

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

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

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

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

Thank you ! (Questions ?)