Lile Hattori

Syde: a tool for collaborative software development

Team collaboration is essential for the success of multi-developer projects. When team members are spread across different locations, individual awareness of the activity of others drops due to communication barriers. We built Syde, a tool infrastructure to reestablish team awareness by sharing change and conflict information across developers workspaces. Our main challenge is to balance the tradeoff between offering relevant information about the activity of the team and avoiding information overload. The novelty of our approach is that we model source code changes as first-class entities to record the detailed evolution of a multi-developer project. Hence, Syde delivers precise change information to interested developers.

On the nature of commits

Information contained in versioning system commits has been frequently used to support software evolution research. Concomitantly, some researchers have tried to relate commits to certain activities, e.g., large commits are more likely to be originated from code management activities, while small ones are related to development activities. However, these characterizations are vague, because there is no consistent definition of what is a small or a large commit. In this paper, we study the nature of commits in two dimensions. First, we define the size of commits in terms of number of files, and then we classify commits based on the content of their comments. To perform this study, we use the history log of nine large open source projects.

Supporting Collaboration Awareness with Real-Time Visualization of Development Activity

In the context of multi-developer projects, where several people are contributing code, developers must deal with concurrent development. Collaboration among developers assumes a fundamental role, and failing to address it can result, for example, in shipping delays. We argue that tool support for collaborative software development augments the level of awareness of developers, and consequently, help them to collaborate and coordinate their activities. In this context, we present an approach to augment awareness by recovering development information in real time and broadcasting it to developers in the form of three lightweight visualizations. Scamp, the Eclipse plug-in supporting this, is part of our Syde tool to support collaboration. We illustrate the usage of Scamp in the context of two multi-developer projects.

Software Evolution Comprehension: Replay to the Rescue

Developers often need to find answers to questions regarding the evolution of a system when working on its code base. While their information needs require data analysis spanning over different repository types, the source code repository has a pivotal role for program comprehension tasks. However, the coarse-grained nature of the data stored by commit-based software configuration management systems often makes it challenging for a developer to search for an answer. We present Replay, an Eclipse plug-in that allows one to explore the change history of a system by capturing the changes at a finer granularity level than commits, and by replaying the past changes chronologically inside the integrated development environment with the source code at hand. We conducted a controlled experiment to empirically assess whether Replay outperforms a baseline (SVN client in Eclipse) on helping developers to answer common questions related to software evolution. The experiment shows that Replay leads to a decrease in completion time with respect to a set of software evolution comprehension tasks.

Replaying past changes in multi-developer projects

What was I working on before the weekend? and What were the members of my team working on during the last week? are common questions that are frequently asked by a developer. They can be answered if one keeps track of who changes what in the source code. In this work, we present Replay, a tool that allows one to replay past changes as they happened at a fine-grained level, where a developer can watch what she has done or understand what her colleagues have done in past development sessions. With this tool, developers are able to not only understand what sequence of changes brought the system to a certain state (e.g., the introduction of a defect), but also deduce reasons for why her colleagues performed those changes. One of the applications of such a tool is also discovering the changes that broke the code of a developer.

Telling stories about GNOME with Complicity

Traditionally, the target of software evolution research has been single software systems. However, in the recent years, researchers observed that software systems are often not developed in isolation, but within a larger context: the ecosystem level. Analyzing software evolution at the ecosystem level allows a better understanding of the evolution phenomenon, as the entire development context can be studied. Nonetheless, software ecosystem analysis is challenging because of the sheer amount of data to be processed and understood. We present Complicity, a web-based application that supports software ecosystem analysis by means of interactive visualizations. Complicity breaks down the data quantity by offering two abstraction levels: ecosystem and entity. To support a thorough exploration and analysis of ecosystem data, the tool provides a number of fixed viewpoints and the possibility of creating new viewpoints with given software metrics. We illustrate in a case study how Complicity can help to understand the GNOME ecosystem in a bottom-up approach, starting from a single project and contributor towards their impact on the ecosystem.

An environment for synchronous software development

Collaboration is essential for the development of complex software systems. When a team of developers is geographically distributed, collaboration aspects -such as awareness, communication and synchronization- are compromised by physical distance. We present an approach, named synchronous development, to reduce the negative distance effects on collaboration. We use a fine-grained change tracking mechanism and instantaneously notify any developer working on the system about changes being performed by other developers. We believe that our approach can augment each developers knowledge of the project and, consequently, promote interaction and increase productivity.

Refining code ownership with synchronous changes

When mining software repositories, two distinct sources of information are usually explored: the history log and snapshots of the system. Results of analyses derived from these two sources are biased by the frequency with which developers commit their changes. We argue that the usage of mainstream SCM (software configuration management) systems influences the way that developers work. For example, since it is tedious to resolve conflicts due to parallel commits, developers tend to minimize conflicts by not contemporarily modifying the same file. This however defeats one of the purposes of such systems. We mine repositories created by our tool Syde, which records changes in a central repository whenever a file is compiled locally in the IDE (integrated development environment) by any developer in a multi-developer project. This new source of information can augment the accuracy of analyses and breaks new ground in terms of how such information can assist developers. We illustrate how the information we mine provides a refined notion of code ownership with respect to the one inferred by SCM system data. We demonstrate our approach on three case studies, including an industrial one. Ownership models suffer from the assumption that developers have a perfect memory. To account for their imperfect memory, we integrate into our ownership measurement a model of memory retention, to simulate the effect of memory loss over time. We evaluate the characteristics of this model for several strengths of memory.

Answering software evolution questions

ContextDevelopers often need to find answers to questions regarding the evolution of a system when working on its code base. While their information needs require data analysis pertaining to different repository types, the source code repository has a pivotal role for program comprehension tasks. However, the coarse-grained nature of the data stored by commit-based software configuration management systems often makes it challenging for a developer to search for an answer. ObjectiveWe present Replay, an Eclipse plug-in that allows developers to explore the change history of a system by capturing the changes at a finer granularity level than commits, and by replaying the past changes chronologically inside the integrated development environment, with the source code at hand. MethodWe conducted a controlled experiment to empirically assess whether Replay outperforms a baseline (SVN client in Eclipse) on helping developers to answer common questions related to software evolution. ResultsThe experiment shows that Replay leads to a decrease in completion time with respect to a set of software evolution comprehension tasks. ConclusionWe conclude that there are benefits in using Replay over the state of the practice tools for answering questions that require fine-grained change information and those related to recent changes.

Manhattan: Supporting real-time visual team activity awareness

Collaboration is essential for the development of complex software systems. An important aspect of collaboration is team awareness: The understanding of the activity of others that provides a context for ones activity. We claim that the current IDE support for awareness is inadequate: The typical setting is to rely on software configuration management systems (SCMs), which are based on an explicit check-out/check-in model. If developers rely only on SCMs information, they become aware of concurrent changes only when they commit their code to the repository. This generates problems such as complex merging and redundant work. Most tools to raise awareness notify developers of emerging conflicts in the form of textual notifications. We propose to improve the notification by using real-time visualization integrated in the IDE to notify developers of team activity. Our approach, implemented in a tool called Manhattan, eases team activity comprehension by relying on a city metaphor. Manhattan depicts a software system as a live city that changes as the underlying system evolves. Within the city, Manhattan renders team activity information, updating developers in real-time about changes implemented by the entire development team. Further, Manhattan provides programmers with immediate feedback about emerging conflicts in which they are involved.