Software developers have long known that project success requires a robust understanding of both technical and social linkages. However, research has largely considered these independently. Research on networks of technical artifacts focuses on techniques like code analysis or mining project archives. Social network analysis has been used to capture information about relations among people. Yet, each type of information is often far more useful when combined, as when the “goodness ” of social networks is judged by the patterns of dependencies in the technical artifacts. To bring such information together, we have developed Tesseract, an interactive exploratory environment that utilizes cross-linked displays to visualize the myriad relationships between artifacts, developers, bugs, and communications. We evaluated Tesseract by (1) demonstrating its feasibility with GNOME project data (2) assessing its usability via informal user evaluations, and (3) verifying its suitability for the open source community via semi-structured interviews. 1.

In this paper, we present results from our empirical evaluations of a workspace awareness tool that we designed and implemented to augment the functionality of software configuration management systems. Particularly, we performed two user experiments directed at understanding the effectiveness of a workspace awareness tool in improving coordination and reducing conflicts. In the first experiment, we evaluated the tool through text-based assignments to avoid interference from the well-documented impact of individual differences among participants, as these differences are known to lessen the observable effect of proposed tools or to lead to them having no observable effect at all. This strategy of evaluating an application in a domain that is known to have less individual differences is novel and in our case particularly helpful in providing baseline quantifiable results. Upon this baseline, we performed a second experiment, with code-based assignments, to validate that the tool’s beneficial effects also occur in the case of programming. Together, our results provide quantitative evidence of the benefits of workspace awareness in software configuration management, as we demonstrate that it improves coordination and conflict resolution without inducing significant overhead in monitoring awareness cues.

Abstract. For the versioning of code a pantheon of version control system (VCS) solutions has been realized and is successfully applied in practice. Nevertheless, when it comes to merging two different versions of one artifact, the resolution of conflicts poses a major challenge. In standard systems, the developer who performs the later commit is sole in charge of this often time-consuming, error-prone task. This commit carries the inherent danger of losing the modifications of the other developer. Recently, collaborative merge approaches for code versioning systems have been proposed to minimize this risk. In this paper we propose to apply similar techniques in the context of model versioning where the challenge of merging two versions is even more formidable due to their graph-structure and their rich semantics. In particular, modeling is used in the early phases of the software development, where a collaborative merge is beneficial to elaborate a consolidated understanding of a domain.

Previous work has found that the number of defects in a source file is proportional to the number of developers who concurrently access the file. Several “conflict-recommender ” tools have been proposed that can aid programmers in detecting conflicts that lead to such defects. These can be classified according to several design dimensions including how early in the programming process the (potential) conflict is identified; which, if any, of existing software systems must be extended to create the tool; the granularity of the program constructs that are identified as conflicting; the criteria used for identifying conflicts; how the conflict information is obtained; and whether the tool supports individual or collaborative inspection of the conflict. The various points defined by this design space can be analyzed according to several evaluation dimensions including the number of false positives and negatives given by the tool; how much effort is required to find/fix the conflict; the computation and communication costs of the tool; how much change it requires to the current software development process; how much screen realestate is used by the tool during coding; and to what extent is the privacy of programmers invaded. The identification and analysis of these design and evaluation dimensions can lead to better evaluation of the various aspects of existing tools and an integrated tool that combines orthogonal features of different tools.

During collaborative development, individual developers can create conflicts in their copies of the code. Such conflicting edits are frequent in practice, and resolving them can be costly. We present Crystal, a tool that proactively examines developers ’ code and precisely identifies and reports on textual, compilation, and behavioral conflicts. When conflicts are present, Crystal enables developers to resolve them more quickly, and therefore at a lesser cost. When conflicts are absent, Crystal increases the developers ’ confidence that it is safe to merge their code. Crystal uses an unobtrusive interface to deliver pertinent information about conflicts. It informs developers about actions that would address the conflicts and about people with whom they should communicate.

Most software is built by multiple people, and a version control system integrates evolving individual contributions into a whole. Every engineer makes decisions about when to incorporate other team members ’ changes, and when to share changes with other team members. Sometimes, an engineer performs these tasks too early, and in other cases performs them too late. In this paper we address several questions to determine if there are enough situations in practice where an individual could benefit from explicit knowledge about the relationship between their view of the software with respect to other views of the software. In particular, we speculate (in principle) at each moment in time about whether unrecognized conflicts with teammates exist and whether there are unnoticed opportunities for straightforward merging among teammates. To determine whether there are sufficient potential opportunities — needed to justify the design, implementation, and evaluation of a speculative tool — we analyze existing source code repositories. Across several open-source projects, we compute and report results including how long conflicts persist before they are resolved (a mean of 9.8 days) and how long opportunities for a non-conflicting textual merge persist (a mean of 11 days). In addition, for one of the projects, we compare the persistence of textual conflicts vs. compilation conflicts vs. testing conflicts. Our data show that there is ample opportunity to benefit from speculative version control, justifying a tool design and implementation effort. 1.

Synchronous groupware depends on the assumption that people are fully connected to the others in the group, but there are many situations (network delay, network outage, or explicit departure) where users are disconnected for various periods. There is little research dealing with disconnection in synchronous groupware from a user and application perspective; as a result, most current groupware systems do not handle disconnection events well, and several user-level problems occur. To address this limitation, we developed the Disco framework, a model for handling several types of disconnection in synchronous groupware. The framework considers how disconnections are identified, what senders and receivers should do during an absence, and what should be done with accumulated data upon reconnection. We have implemented the framework in three applications that show the feasibility, generality, and functionality of our ideas. Our framework is the first to deal with a full range of disconnection issues for synchronous groupware, and shows how groupware can better support the realities of distributed collaboration.

We introduce a new method for determining work dependencies that are antecedents to coordination requirements among members of a software development organization. Our method leverages records of individual activity associated with development tasks, sometimes called task context, which can be collected by monitoring the actions carried out by a developer during work sessions within her development environment. We describe an algorithm that measures similarity between task contexts and produces a measure of closeness between the corresponding developers. By means of a field study on an open source project that routinely records task context data, we show how the closeness relationship accurately determines the same coordination requirements detected using traditional methods. Our method also provides a temporal advantage, since it uses “live” instead of historical data. We explain how these findings make coordination requirements actionable for management-, designand team-related decisions as the development work is underway. This moves research in this area from post-mortem analysis to proactive detection of coordination requirements.

Most software tools and environments help developers analyze the present and past development states of their software systems. Few approaches have investigated the potential consequences of future actions the developers may perform. The commoditization of hardware, multi-core architectures, and cloud computing provide new potential for delivering apparently-instantaneous feedback to developers, informing them of the effects of changes that they may be considering to the software. For example, modern IDEs often provide “quick fix ” suggestions for resolving compilation errors. Developers must scan this list and select the option they think will resolve the problem. Instead, we propose that the IDE should speculatively perform each of the suggestions in the background and provide information that helps developers select the best option for the given context. We believe the feedback enabled by speculative operations can improve developer productivity and software quality.

Abstract. Intensive research and development has been conducted in the design and creation of groupware systems for distributed users. While for some activities, these groupware tools are widely used, for other activities the impact in the groupware community has been smaller and can be improved. One reason for this fact is that the mostly common used applications do not support collaborative features and users are reluctant to change to a different application. In this paper we discuss how available file system mechanisms can help to address this problem. In this context, we present Forby, a system that allows to provide groupware features to distributed users by combining filesystem monitoring and distributed event dissemination. To demonstrate our solution, we present three systems that rely on Forby for providing groupware features to users running unmodified applications. 1