Collaborative Development Environment using Visual Studio
Collaborative Development Environment using Visual Studio

CollabVS is an effort to introduce collaboration and multiparty, distributed software development enhancements into Visual Studio.


CollabVS is a Visual Studio extension (research prototype) that augments the user experience with functionality aimed at collaborative, distributed development.

CollabVS is an effort to introduce collaboration and multiparty, distributed software development enhancements into Visual Studio. A side-effect of this is an enhanced user experience even when the collaborating developers are co-located.

Key Thoughts Behind the Idea

When software is developed collaboratively, a number of problems arise. It is hard to get in touch with the right people or have the right information. Moreover, a large number of concurrent accesses to the same piece of code are made, resulting in increased defects. These problems get aggravated when people collaborate across geographically dispersed sites, and reduced when they are collocated in a single war room or program in pairs. Software development environments offered by IBM, Sun and Apple have incorporated some novel features to address these problems. There is no single IDE that supports rich collaboration (through detailed presence information and lightweight communication tools) and distributed development tools (e.g. Pair programming). Through this project, we address some of these problems by enhancing Visual Studio with real-time collaboration and tools for multiple developersto program together, whether distributed or co-located.

Collaborative Tools, Activities andTypes

CollabVS allows developers to work together whether intentional or ad-hoc. For example, pair of developers can agree to work together at a scheduled time and work together using CollabVS. On the other hand, CollabVS allows for opportunistic collaboration as well. Developes can carry out various activities using the tools provided by CollabVS. Some of these "facets" of CollabVS are shown in the cube below.

Feature Areas

Real-time Presence information compensates forthe team members not being in the same room to see what's going on. Consequently it's goal is to let the user know what the other team members are doing. It fosters ad-hoc collaboration when the team is dsitributed by creating a virtual environment. Example: show what users are online and whether they're editing, debugging, engaged in an instant messaging session, etc.

Contextual Presence facilitates finding relevant information and people quickly. The goal is to provide information based on the context of artifacts that otherwise would have to be extracted manually. Example: show who has an artifact checked out, last few team members who checked in the artifact, last few changes made to the artifact, the tests associated with the artifact and the testers assigned to them.

Communication tools also compensate for the team members not being in the same room to talk to each other. They aim at allowing a user to engage in rich information exchanges with the other team members, in a seamless manner (i.e., without context switching to other tools). Example: provide the ability to start an instant messaging session, an audio/video session, or a shared whiteboard, allfrom the development environment.

Collaborative development tools change the user experience by augmenting the traditional IDE with support for collaborative activities. These tools aim at providing support for collaborative software construction. Example: collaborative code review, where the development environment allows the user to find reviewers (presence), initiate the conversation (communication), co-annotate the code under review, and sign off the reviewed code, without leaving the environment.

  • Prasun Dewan, Puneet Agrawal, Gautam Shroff, and Rajesh Hegde, Experiments in Distributed Side-By-Side Software Development, in CollaborateCom 2009. 5th International Conference on Collaborative Computing: Networking, Applications and Worksharing, IEEE Computer Society, 11 November 2009
    In distributed side-by-side software development, a pair of distributed team members are assigned a single task and allowed to (a) work concurrently on two different computers and (b) see each others' displays. They can control when they communicate with each other, view each others' actions, and input concurrently. To understand how this control is exerted in practice, we have performed experiments at two different organizations, Microsoft Research and Tata Consultancy Services, which involved about forty six person hours of distributed side-by-side development. The experimental tasks were typical of the kind carried out at these organizations. A mix of qualitative, quantitative, and visualization analysis shows shows that (a) distribution and conflicting changes are not an issue; (b) developers use the unique capabilities provided by distributed side-by-side software development; and (c) the exact usage depends on several factors such as the collaboration task, developers, and software-development abstraction and environment.
  • Prasun Dewan, Puneet Agarwal, Gautam Shroff, and Rajesh Hegde, Distributed Side-by-Side Programming, in ICSE Workshop on Cooperative and Human Aspects on Software Engineering, 2009. CHASE '09. , IEEE, 18 May 2009
    Recent work has proposed a variation of pair programming called side-by-side programming,wherein two programmers, sitting next to each other and using different workstations, work together on the same task. We have defined a distributed approximation of this idea and implemented it in both a compiled and interpretive environment. Our experiments with these implementations provide several new preliminary results regarding different aspects of (distributed) side-by-side programming.
  • Rajesh Hegde and Prasun Dewan, Connecting Development Environments to Support Ad-Hoc Collaboration, in 23rd IEEE/ACM International Conference on Automated Software Engineering, Institute of Electrical and Electronics Engineers, Inc., 18 September 2008
    Physical proximity supports various forms of ad-hoc collaboration among developers such as opportunistic task adaptation and helping co-developers when they are stuck . Connecting the input/output flows of stand-alone programming environments of distributed developers offers the potential to support such collaboration among them. Such a connection has several components including communication sessions, awareness of others’ availability and the state of the objects on which they are working, and control channels allowing users to import edits of and share code with others and be notified when a team member has moved away from a program element of interest. It is possible to develop a collaboration-centered design that combines a variety of collaboration streams into a usable and useful user-interface, and implement the design using existing programming environment, communication, and compiler technologies.
  • Prasun Dewan and Rajesh Hegde, Semi-Synchronous Conflict Detection and Resolution in Asynchronous Software Development, in Proceedings of the 2007 Tenth European Conference on Computer-Supported Cooperative Work, Springer Verlag, 25 September 2007
    Previous work has found that (a) when software is developed collaboratively, concurrent accesses to related pieces of code are made, and (b) when these accesses are coordinated asynchronously through a version control system, they result in increased defects because of conflicting concurrent changes. Previous findings also show that distance collaboration aggravates software-development problems and radical colocation reduces them. These results motivate a semi-synchronous distributed computer supported model that allows programmers creating code asynchronously to synchronously collaborate with each other to detect and resolve potentially conflicting tasks before they have completed the tasks. We describe, illustrate, and evaluate a new model designed to meet these requirements. Our results show that the model can catch conflicts at editing time that would be expensive to manage at later times.