This paper proposes a framework for describing, comparing and understanding visualization tools that provide awareness of human activities in software development. The framework has several purposes – it can act as a formative evaluation mechanism for tool designers; as an assessment tool for potential tool users; and as a comparison tool so that tool researchers can compare and understand the differences between various tools and identify potential new research areas. We use this framework to structure a survey of visualization tools for activity awareness in software development. Based on this survey we suggest directions for future research.

Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers comprehend software, as well as the tools that are used to assist in comprehension tasks. During this talk I will review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I will then explore how tools that are popular today have evolved to support program comprehension. Specifically, I will discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools will be further differentiated according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I will predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tools and methods. 1.

This paper presents the conceptual design of TagSEA, a collaborative tool to support asynchronous software development. Our goal is to develop a lightweight source code annotation tool that enhances navigation, coordination, and capture of knowledge relevant to a software development team. Our design is inspired by combining “waypoints ” from geographical navigation with “social tagging ” from social bookmarking software to support coordination and communication among software developers. We describe the motivation behind this work, walk through the design and implementation, and report early feedback on how this lightweight tool supports collaborative software engineering activities. Finally, we suggest a number of new research directions that this topic exposes.

The contents of this work reflect the views of the authors who are responsible for the facts and accuracy of the data presented. Responsibility for the application of the material to specific cases, however, lies with any user of the report and no responsibility in such cases will be attributed to the author or to the University of Canterbury. This technical report contains a research paper, development report, or tutorial article which has been submitted for publication in a journal or for consideration by the commissioning organisation. We ask you to respect the current and future owner of the copyright by keeping copying of this article to the essential minimum. Any requests for further copies should be sent to the author. Caise, a collaborative software engineering architecture, provides extensible real-time support for collaboration between participating tools and users. The architecture maintains a semantic project model constructed incrementally from software artifacts as they are developed; this model is used to determine the impact of changes at a semantic level. This information is relayed to developers, providing them with awareness of others ’ locations, and alerting them to potential conflicts and the need for closer collaboration. We use examples from Caise-based tools to illustrate the potential of real-time collaborative software engineering to enhance awareness of other developers ’ actions. 1

Social networking systems help people maintain connections to their friends, enabling awareness, communication, and collaboration, especially at a distance. In many studies of coordination in software engineering, the work artifacts, e.g. code, bugs, specifications, are themselves the objects that link engineers together. In this paper, we introduce Codebook, a social networking web service in which people can be “friends ” not only with other people but with the work artifacts they share with them. Providing a web interface to the graph of these connections will enable software engineers to keep track of task dependencies, discover and maintain connections to other teams, and understand the history and rationale behind the code that they work on and use. 1.

Large-scale software development requires coordination within and between very large engineering teams, each of which may be located in different locations and time zones. Numerous studies, and indeed, a whole conference (ICGSE), are dedicated to discovering the causes of problems with distributed development in the software industry. Microsoft has long had product teams too large to be considered co-located, even when sitting in neighboring buildings on the same campus. Recently, it has been expanding its engineering workforce into India and China, and our research is showing that Microsoft is encountering many of the coordination problems that go along with differences of location, time zone, and culture. As we go forward, our research has been changing from learning about the problem to experimenting with solutions. What are the best practices for improving coordination? Can they be applied to all software teams? How does one move past simple readings of research results towards effective intervention?

When faced with the need for documentation, examples, bug fixes, error descriptions, code snippets, workarounds, templates, patterns, or advice, software developers frequently turn to their web browser. Web resources both organized and authoritative as well as informal and communitydriven are heavily used by developers. The time and attention devoted to finding (or re-finding) and navigating these sites is significant. We present Codetrail, a system that demonstrates how the developer’s use of web resources can be improved by connecting the Eclipse IDE and the Firefox web browser. Codetrail uses a communication channel and shared data model between these applications to implement a variety of integrative tools. By combining information previously available only to the IDE or the web browser alone (such as editing history, code contents, and recent browsing), Codetrail can automate previously manual tasks and enable new interactions that exploit the marriage of data and functionality from Firefox and Eclipse. Just as the IDE will change the contents of peripheral views to focus on the particular code or task with which the developer is engaged, so, too, the web browser can be focused on the developer’s current context and task. 1.

Abstract Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers understand software, as well as the tools that are used to assist in comprehension tasks. In this paper, I review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I then explore how tools that are commonly used today have evolved to support program comprehension. Specifically, I discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools are distinguished according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tool development and research methods.

Despite the fact that software development is an inherently collaborative activity, a great deal of software development is spent with developers in isolation, working on their own parts of the system. In these situations developers are unaware of parallel changes being made by others, often resulting in conflicts. One common approach to deal with this issue is called conflict resolution, which means that changes have already been checkedin and developers must use merge tools to resolve conflicts and then retest the code to ensure its correctness. Unfortunately, this process becomes more difficult the longer the conflicts go undetected. In order to address these issues, have been proposed conflict avoidance approaches that detect conflicts as soon as they occur. In this paper, we present Lighthouse, an Eclipse plug-in that takes the conflict avoidance approach to coordinate developers. Lighthouse distinguishes itself by utilizing a concept called emerging design, an up to date design representation of the code, to alert developers of potentially conflicting implementation changes as they occur, indicating where the changes have been made and by whom.

Large-scale software development requires coordination within and between very large engineering teams which may be located in different buildings, on different company campuses, and in different time zones. At Microsoft Corporation, we studied a 3-year-old, 300-person software application team based in Redmond, WA to learn how they coordinate with three intra-organization, physically distributed dependencies: a platform library team also in Redmond; a team three time zones away in Boston, MA; and a team in Hyderabad, India. Thirty-one interviews with 26 team members revealed that coordination was most impacted by issues of communication, capacity and cooperation. Distributed teams faced additional challenges due to time zone and cultural differences between the team members. We support our findings with a survey of 775 engineers across Microsoft who described their experiences managing coordination in their own software products. We suggest new processes and tools to improve team coordination. 1