We know surprisingly little about how professional developers define debugging and the challenges they face in industrial environments. To begin exploring professional debugging challenges and needs, we conducted and analyzed interviews with 15 professional software engineers at Microsoft. The goals of this study are: 1) to understand how professional developers currently use information and tools to debug, 2) to identify new challenges in debugging in contemporary software development domains (web services, multithreaded/multicore programming), and 3) to identify the improvements in debugging support desired by these professionals that are needed from research. The interviews were coded to identify the most common information resources, techniques, challenges, and needs for debugging as articulated by the developers. The study reveals several debugging challenges faced by professionals, including: 1) the interaction of hypothesis instrumentation and software environment as a source of debugging difficulty, 2) the impact of log file information on accurate debugging of web services, and 3) the mismatch between the sequential human thought process and the non-sequential execution of multithreaded environments as source of difficulty. The interviewees also describe desired improvements to tools to support debugging, many of which have been discussed in research but not transitioned to practice.

Software is created by people---software engineers---working in varied environments, under various conditions. Thus understanding cooperative and human aspect of software development is crucial to comprehend how methods and tools are used, and thereby improving the creation and maintenance of software. Inspired by the hosting country's concept of co-responsibility -- ubuntu -- we especially invited contributions that address community-based development like open source development and sustainability of ICT eco-systems.

Developers frequently add annotations to source code to help them remember pertinent information and mark locations of interest for future investigation. Finding and refinding these notes is a form of navigation that is integral to software maintenance. Although there is some tool support in modern development environments for authoring and navigating these comments, we have observed that these annotations often fail to remind and are sometimes difficult to find by the programmer. To address these shortcomings, we have designed a new approach for software navigation called tags for software engineering activities (TagSEA). TagSEA combines the notion of waypointing (a mechanism for marking locations in spatial navigation) with social tagging to support programmers in defining semantically rich annotations to source code comments. The tool provides support for creating, editing, navigating, and managing these annotations. We present the results from two empirical studies, where we observed and then analyzed how professional programmers used source code annotations to support their development activities over 24 months. Our findings indicate that the addition of semantic information to annotations can improve their value. We also provide suggestions on how annotation tools in general may be improved.

Software development is a highly collaborative activity that requires teams of developers to continually manage and coordinate their programming tasks. In this paper, we describe an empirical study that explored how task annotations embedded within the source code play a role in how software developers manage personal and team tasks. We present findings gathered by combining results from a survey of professional software developers, an analysis of code from open source projects, and interviews with software developers. Our findings help us describe how task annotations can be used to support a variety of activities fundamental to articulation work within software development. We describe how task management is negotiated between the more formal issue tracking systems and the informal annotations that programmers write within their source code. We report that annotations have different meanings and are dependent on individual, team and community use. We also present a number of issues related to managing annotations, which may have negative implications for maintenance. We conclude with insights into how these findings could be used to improve tool support and software process.

Global software teams face challenges when collaborating over long distances, such as communicating changes in the project. During a four-month case study at IBM Ottawa Software Lab we observed the collaboration patterns of a multi-site development project team. In this period, we inspected project documentation, interviewed team leaders, attended project meetings, and spoke with developers to identify problems originated by the lack of awareness of changes related to the implementation of work items. Our observations show (1) that organizational culture has an effect on how developers are made aware; (2) that communication-based social networks revolving around particular work items are dynamic throughout development, and therefore awareness needs to be maintained in infrastructures of work; and (3) that information overload and communication breakdowns contributed to the generation of a broken integration build. We discuss these breakdowns in communication and implications for the design of collaboration tools that could mitigate these problems.

We have developed a new approach for software navigation called TagSEA (Tagging of Software Engineering Activities). TagSEA combines the notion of "waypointing" with "social tagging" to support programmers in defining navigational structures over a software system. In this paper we present the results from a case study series, conducted with professional programmers, that demonstrates how this tool supports navigation and under what circumstances. We conclude with insights into user-definable navigational structures, and how they can support software maintenance more effectively.

Ever wonder how your tool would fare in the 'real world'? Think your tool excels where others have failed? Is your tool better than a software developer? How can your tool help a software developer? Have you asked these kinds of questions before? If so, then this mini-tutorial is focused on your needs. In the mini-tutorial, I will go over the basics of tool evaluation from the beginning to end, from ethics to theory to analysis. Both qualitative and quantitative approaches will be covered

In this paper, we present NavTracks, a tool that supports browsing through software. NavTracks keeps track of the navigation history of software developers, forming associations between related files. These associations are then used as the basis for recommending potentially related files as a developer navigates the software system. We present the reasoning behind NavTracks, its basic algorithm, a case study, and propose some future work.

Sociological and technical difficulties, such as a lack of informal encounters, can make it difficult for new members of noncollocated software development teams to learn from their more experienced colleagues. To address this situation, we have developed a tool, named Hipikat that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This project memory is built automatically with little or no change to existing work practices. After describing the Hipikat tool, we present two studies investigating Hipikat's usefulness in software modification tasks. One study evaluated the usefulness of Hipikat's recommendations on a sample of 20 modification tasks performed on the Eclipse Java IDE during the development of release 2.1 of the Eclipse software. We describe the study, present quantitative measures of Hipikat's performance, and describe in detail three cases that illustrate a range of issues that we have identified in the results. In the other study, we evaluated whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. We describe the study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

The lack of lightweight communication channels and other technical and sociological difficulties make it hard for new members of a non-collocated software development team to learn effectively from their more experienced colleagues while they are coming up-to-speed on a project. To address this situation, we have developed a tool, named Hipikat, that provides developers with efficient and effective access to the group memory for a software development project that is implicitly formed by all of the artifacts produced during the development. This project memory is built automatically with little or no change to existing work practices. We report an exploratory case study evaluating whether software developers who are new to a project can benefit from the artifacts that Hipikat recommends from the project memory. To assess the appropriateness of the recommendations, we investigated when and how developers queried the project memory, how the evaluated the recommended artifacts, and the process by which they utilized the artifacts. We found that newcomers did use the recommendations and their final solutions exploited the recommended artifacts, although most of the Hipikat queries came in the early stages of a change task. We describe the case study, present qualitative observations, and suggest implications of using project memory as a learning aid for project newcomers.

A layered architecture for advanced collaborative environments has been developed to map the definition of a collaboration task from the requirements needed, to accomplish the task to the collaboration services that can be used to satisfy those needs, and to the technologies on which the services can be delivered. The architecture takes into account the users' goals and needs in configuring the services required for a collaboration task. By understanding and designing for users' needs and requirements, we can ensure a high quality of experience (QoE). The architecture was used to create a prototype system that is currently being tested through user studies.

The popularity of empirical methods in software engineering research is on the rise. Surveys, experiments, metrics, case studies, and field studies are examples of empirical methods used to investigate both software engineering processes and products. The increased application of empirical methods has also brought about an increase in discussions about adapting these methods to the peculiarities of software engineering. In contrast, the ethical issues raised by empirical methods have received little, if any, attention in the software engineering literature. This article is intended to introduce the ethical issues raised by empirical research to the software engineering research community and to stimulate discussion of how best to deal with these ethical issues. Through a review of the ethical codes of several fields that commonly employ humans and artifacts as research subjects, we have identified major ethical issues relevant to empirical studies of software engineering. These issues are illustrated with real empirical studies of software engineering.

The goal of this workshop is to provide an interactive forum for software engineers and empirical researchers to investigate the feasibility of applying proven methods from other research disciplines to software engineering research. Participants submitted position papers describing problems that might benefit from a multidisciplinary approach. Expert guest speakers from software engineering and other disciplines will address the issues highlighted in the papers with the goal of encouraging more multidisciplinary research.

We suggest that empirical studies of maintenance are difficult to understand unless the context of the study is fully defined. We developed a preliminary ontology to identify a number of factors that influence maintenance. The purpose of the ontology is to identify factors that would affect the results of empirical studies. We present the ontology in the form of a UML model. Using the maintenance factors included in the ontology, we define two common maintenance scenarios and consider the industrial issues associated with them. Copyright © 1999 John Wiley & Sons, Ltd.

This paper describes the results of an interview study conducted at ten industrial sites. The interview focused on the work practices of software engineers engaged in maintaining large scale systems. Five 'truths' emerged from this study. First, software maintenance engineers are experts in the systems they are maintaining. Second, source code is the primary source of information about systems. Third, the documentation is used, but not necessarily trusted. Fourth, maintenance control systems are important repositories of information about systems. Finally, reproduction of problems and/or problem scenarios is essential to problem solutions. These truths confirm much of the conventional wisdom in the field. However, in fleshing them out, details were elaborated, and additionally new knowledge was acquired. These results are discussed with respect to tool design.

This paper will discuss a framework and methodology for understanding the use of computers in collaborative learning. In particular, we are interested in how learning occurs when students work together using a computer microworld. Collaborative settings provide a particularly rich environment for studying learning. Many theorists (see Brown and Palinscar, in press) have proposed that learning occurs when students have to explain, develop, or justify their ideas to others. In a collaborative setting, students communicate their ideas in order to coordinate their activity towards shared goals. When dilemmas arise in the course of productive work, the combination of communication and activity can lead to learning (Vygotsky 1978, Dewey 1923, Mead 1934).