New technologies often change how an individual performs work, such as how generative AI (GenAI) can help a developer write code. New technologies can also impact how people interact with one another, such as how GenAI’s ability to summarize API documentation can reduce the need for developers to ask each other technical questions. In this paper, we report on a two-phase mixed-method study exploring how GenAI influences how humans interact in software development. During phase one, 30 industrial software developers provided data over a period of 5 to 12 days as they worked, contributing 627 experience sampling responses and 207 end-of-workday survey responses. To gain further insight into their work, we interviewed 22 of these developers. During phase two, 131 additional professional developers responded to a survey to explore whether and how the results from phase one are seen across a larger population. Our analysis of the data found that (1) the ability of GenAI to help answer low-level technical questions in a timely way enables developers to see GenAI as a technical mentor, providing opportunities for developers to turn to tools rather than teammates; (2) developers perceive that GenAI can help them experience more focus and experience fewer flow disruptions; (3) GenAI can help developers pursue more meaningful conversations with their colleagues by shifting human interaction towards clarification, joint reasoning, and exploring alternative perspectives; and (4) in the presence of GenAI, developers report still seeking human-to-human interaction for contextual expertise, mentorship, and social connection. Together, these findings showwhat changes,when it changes, andwhat teams can do nextin response to this shift in team interaction dynamics, where GenAI increasingly handles routine technical queries and human conversations center on context, reasoning, and connection. Teams can adopt norms for delegating questions, sustain human judgment in complex decisions, and create space for expertise, mentorship, and connection, alongside increasing technical self-sufficiency.

Knowledge workers face increasing challenges in managing numerous digital tasks, often leading to long task lists that distract from completing the most important ones.We present AIRbar, a task management tool designed to enhance Awareness, I ntention, and Retrospection (AIR) in daily task management.AIRbar prompts workers to prioritize a maximum of three daily tasks, displays them in an always-on glanceable widget, and facilitates end-of-day reflection to improve task completion and self-awareness.In a 4-week field study with 35 participants, we found that AIRbar increased task completion rates, improved focus and motivation, and positively influenced perceptions of work processes.These findings suggest that limiting the number of tasks and ensuring continuous visibility of priorities can address key challenges in modern task management, providing actionable insights for designing future task management systems.

Since the COVID-19 Pandemic, the knowledge workplace has seen a dramatic transition from collocated-first to hybrid or fully-remote arrangements, the implications of which are yet to be fully understood. One of the biggest unknowns is how remote team communication impacts the individual worker, especially in consideration of personality type. The aim of this study is to investigate the effects of remote workplace interactions on productivity and wellbeing, and how these effects are moderated by extraversion. The study lasted for 2-3 months and involved 60 knowledge workers. The data was analyzed using a combination of quantitative and qualitative methods. We present novel findings on how remote communication affects individuals differently depending on the type of interaction, interaction agent, and personality of the individual, showing that the impact of communication on workers is far from straightforward. We contextualize these findings with an in-depth analysis of communication patterns and experiences in the remote workplace, adding to existing literature. Finally, we present suggestions for a more individualized communication approach in industry and future research.

Abstract Developers frequently undertake software change tasks that could be partially or fully automated by refactoring tools. As has been reported by others, all too often, these refactoring steps are instead performed manually by developers. These missed opportunities are referred to as occasions ofdisuseof refactoring tools. We perform an observational study in which 17 developers with professional experience attempt to solve three change tasks with steps amenable to the use of refactoring tools. We found that the strategies developers use to approach these tasks shape their workflow, which, in turn, shape the opportunities for refactoring tool use. We report on a number of findings about developer strategies, demonstrating the difficulty of aligning the kind of refactoring steps that emerge during a change task based on the strategy with the tools available. We also report on findings about refactoring tools, such as the difficulties developers face in controlling the scope of application of the tools. Our findings can help inform the designers of refactoring tools.

The bento-box user interface and tool integration paradigm dominates integrated development environments (IDEs). In this paradigm, tools project different information about a system in disjoint panes (boxes) of a window while integrating updates between them as needed. Although popular and functional, the bento-box paradigm has its drawbacks; previous research has shown that expert developers experience disorientation as they work in these environments. In this paper, we explore how context can be preserved for developers within the bento-box paradigm by introducing and experimenting with a tool named ReachHover. This tool supports the answering of common data-flow reachability questions, which have been previously shown to be difficult for developers to answer. To ensure ReachHover supported practical reachability questions of interest to developers, we conducted, and report on, a formative survey of 72 practicing developers about the type and frequency of reachability questions they encounter in their work. We then conducted, and report on, a controlled user study in which 20 practicing developers used ReachHover, finding that participants who used ReachHover answered questions involving visiting multiple files more correctly than those who used standard tooling, and that those developers better maintained context while determining their answers. These findings demonstrate the potential of introducing context-preserving user interfaces for tools within the standard bento-box paradigm of development environments, opening up new avenues for improved tool expression and adoption.

Software developers handle many complex tasks that include gathering and applying domain knowledge, coordinating subtasks, designing interfaces, turning ideas into elegant code, and more. They must switch contexts between these tasks, incurring more cognitive costs. Recent advances in large language models (LLMs) open up new possibilities for moving beyond the support provided by automated assistants (AAs) available today. In this paper, we explore if a human memory model can provide a framework for the systematic investigation of AAs for software development based on LLMs and other new technologies.

While there has been significant study of both individuals and teams of knowledge workers, research has focused largely on one or the other, with less focus on the interaction between the two. In this paper, we explore the tensions between the individual and their team, focusing on the choices an individual makes towards their own productivity versus their team's productivity. We developed a technology probe with a team nudge that fosters recurring reflection and prompts individuals to consider how their team helps them to be productive. We examined its impact through a longitudinal field study with 48 participants. We chose to undertake this study with software development teams as they are examples of knowledge workers who collaborate on a shared set of tasks with specific goals. Our exploration took place with hybrid development teams, which have increasingly become the norm. Our analysis of a total of 8338 hourly self-reports and 1389 daily diary entries found that the team nudge increased participants' productivity ratings and team awareness, led to participants spending more time on their own tasks, reshaped their perceptions of themselves and their team, yet, in general, did not increase team cohesion or affect well-being.

Software development is a collaborative process requiring a careful balance of focused individual effort and team coordination. Though questions of individual productivity have been widely examined in past literature, less is known about the interplay between developers' perceptions of their own productivity as opposed to their team's. In this paper, we present an analysis of 624 daily surveys and 2899 self-reports from 25 individuals across five software teams in North America and Europe, collected over the course of three months. We found that developers tend to operate in fluid team constructs, which impacts team awareness and complicates gauging team productivity. We also found that perceived individual productivity most strongly predicted perceived team productivity, even more than the amount of team interactions, unplanned work, and time spent in meetings. Future research should explore how fluid team structures impact individual and organizational productivity.

The creation of techniques, languages and tools to support building software from modular parts has enabled the development and evolution of large complex software systems. For many years, the focus of modularity was on the structure of the software system. The thinking was that the right modularity would enable software teams involved in different pieces of the system to work as independently as possible. As a community, we learned over the years that a system has no one optimal modularity, and in fact, the work that is undertaken to add new features or fix defects often crosscuts the modularity of the software. The research we conducted on task contexts and Mylyn over fifteen years ago recognized that capturing the activity performed on development tasks provided a means to make explicit emergent modularity for a system. With Mylyn, we explored how the activity of one developer could enable the surfacing of emergent modularity to help a developer perform tasks on a software system. Through stewardship of the Mylyn open source project and the creation of Tasktop Technologies, we brought these ideas into use in industry. Over the past decade, through interactions with practicing developers and their organizations, we have learned more about how modularity emerges at the individual developer, team, and organizational levels. Tasktop’s products moved accordingly from supporting the activity of individual developers to supporting the streams of value teams within an organization produce. In this talk, we will discuss how following the flow of tasks within software development supports value stream management and outline open research questions about the socio-technical aspects of developing complex software systems.

The information a developer seeks to aid the completion of a task typically exists across a range of artifacts. For example, for a task that requires upgrading to a new version of an API component, a developer may seek information in the API's official documentation, check community discussions about the newer version, and so on. To aid developers in locating the portion of the text that might be useful in these artifacts, prior work has used syntactic properties of the text, and an artifact's meta-data, to automatically identify relevant text for particular kinds of artifacts. Although effective, these techniques rely on assumptions about an artifact's structure or content that prevent applying them across the different types of artifacts that a developer may come across in their daily work. In this paper, we investigate whether techniques building on approaches to interpret the meaning, or semantics, of the text help to overcome these limitations. Particularly, we introduce six semantic-based techniques and evaluate that they can identify up to 58% of the text that developers deem relevant to Android development tasks. When compared to a state-of-the-art approach, we find that our techniques achieve comparable recall values, identifying 63% of the small fraction of the task-relevant text of Stack Overflow artifacts, but without the need for artifact-specific information.

Software design has been considered an integral part of software development for over fifty years. Over this time, software developers have improved how software systems are designed and have determined which designs lead to different desired characteristics in the systems built. In parallel, software engineering researchers have studied the processes software developers use to design and have considered many aspects of software design, such as how to represent a design. Given all of the practical experience gained and all of the study about software design, you might expect that there is a sophisticated common understanding about what software design is and is not. Unfortunately, such a common understanding is not evident in the literature. To investigate how software design is perceived, we conducted an interview study involving 16 participants representing both academia and industry. Our analysis of the interview transcripts reveals five main themes: 1) design cuts across multiple development phases and involves multiple people, 2) design involved decision making, 3) design is impacted by context, 4) design involves communication and 5) good design requires experience. We discuss the implications of these themes and describe what can be done to reach a more commonly shared idea of what design represents.

Developers work on a broad variety of tasks during their workdays and constantly switch between them. While these task switches can be beneficial, they can also incur a high cognitive burden on developers, since they have to continuously remember and rebuild the task context–the artifacts and applications relevant to the task. Researchers have therefore proposed to capture task context more explicitly and use it to provide better task support, such as task switch reduction or task resumption support. Yet, these approaches generally require the developer tomanuallyidentify task switches. Automatic approaches for predicting task switches have so far been limited in their accuracy, scope, evaluation, and the time discrepancy between predicted and actual task switches. In our work, we examine the use ofautomaticallycollected computer interaction data for detecting developers’ task switches as well as task types. In two field studies–a 4h observational study and a multi-day study with experience sampling–we collected data from a total of 25 professional developers. Our study results show that we are able to use temporal and semantic features from developers’ computer interaction data to detect task switches and types in the field with high accuracy of 84 percent and 61 percent respectively, and within a short time window of less than 1.6 minutes on average from the actual task switch. We discuss our findings and their practical value for a wide range of applications in real work settings.

As part of software change tasks, software developers frequently make repetitive and error-prone code changes. Many of these changes can be automated by refactoring tools that are available in mainstream development environments, but developers seldom choose to use them, in large part due to the all-or-nothing approach of the tools. In this paper, we propose an alternative interaction model in which a refactoring tool instead generates a set of code change entities that the developer can inspect, edit, discard, or apply at will. Between applications, the tool supports manual edits or even starting a new refactoring, thus enabling stepwise and recursive refactoring in a way current tools can not. Our model addresses multiple usability problems with refactoring tools. In this paper, we motivate and describe the proposed model and discuss challenges related to its implementation.

Software developers often rely on natural language text that appears in software engineering artifacts to access critical information as they build and work on software systems. For example, developers access requirements documents to understand what to build, comments in source code to understand design decisions, answers to questions on Q&A sites to understand APIs, and so on. To aid software developers in accessing and using this natural language information, soft-ware engineering researchers often use techniques from natural language processing. In this paper, we explore whether frame semantics, a general linguistic approach, which has been used on requirements text, can also help address problems that occur when applying lexicon analysis based techniques to text associated with program comprehension activities. We assess the applicability of generic semantic frame parsing for this purpose, and based on the results, we propose SEFrame to tailor semantic frame parsing for program comprehension uses. We evaluate the correctness and robustness of the approach finding that SEFrame is correct in between 73% and 74% of the cases and that it can parse text from a variety of software artifacts used to support program comprehension. We describe how this approach could be used to enhance existing approaches to identify meaning on intention from software engineering texts.

Although software developers typically have access to numerous refactoring tools, most developers avoid using these tools despite their benefits. Researchers have identified many reasons for the disuse of refactoring tools, including a lack of awareness by the developers, a lack of predictability of the tools, and a lack of need for the tools. In this paper, we build on this earlier work and employ the ISO 9241-11 definition of usability to develop a theory of usability for refactoring tools. We investigate existing refactoring tools using this theory by analyzing how 17 developers experience refactoring tools in three software change tasks we asked them to perform. We analyze qualitatively the resulting interview transcripts based on our theory and report on a number of observations that can inform tool designers interested in improving the usability of refactoring tools. For instance, we found a desire for developers to guide how a refactoring tool changes the code and a need for refactoring tools to describe changes made to developers. Refactoring tools are currently expected to preserve program behavior. These observations indicate that it may be necessary to give developers more control over this property, including the ability to relax it, for the tools to be usable; that is, for the tools to be effective, efficient and satisfying for the developer to employ.

The continuous contributions made by long time contributors (LTCs) are a key factor enabling open source software (OSS) projects to be successful and survival. We study Github as it has a large number of OSS projects and millions of contributors, which enables the study of the transition from newcomers to LTCs. In this paper, we investigate whether we can effectively predict newcomers in OSS projects to be LTCs based on their activity data that is collected from Github. We collect Github data from GHTorrent, a mirror of Github data. We select the most popular 917 projects, which contain 75,046 contributors. We determine a developer as a LTC of a project if the time interval between his/her first and last commit in the project is larger than a certain timeT. In our experiment, we use three different settings on the time interval: 1, 2, and 3 years. There are 9,238, 3,968, and 1,577 contributors who become LTCs of a project in three settings of time interval, respectively. To build a prediction model, we extract many features from the activities of developers on Github, which group into five dimensions: developer profile, repository profile, developer monthly activity, repository monthly activity, and collaboration network. We apply several classifiers including naive Bayes, SVM, decision tree, kNN and random forest. We find that random forest classifier achieves the best performance with AUCs of more than 0.75 in all three settings of time interval for LTCs. We also investigate the most important features that differentiate newcomers who become LTCs from newcomers who stay in the projects for a short time. We find that the number of followers is the most important feature in all three settings of the time interval studied. We also find that the programming language and the average number of commits contributed by other developers when a newcomer joins a project also belong to the top 10 most important features in all three settings of time interval for LTCs. Finally, we provide several implications for action based on our analysis results to help OSS projects retain newcomers.

Software developers are generally interested in developing better habits to increase their workplace productivity and well-being, but have difficulties identifying concrete goals and actionable strategies to do so. In several areas of life, such as the physical activity and health domain, self-reflection has been shown to be successful at increasing people's awareness about a problematic behavior, motivating them to define a self-improvement goal, and fostering goal-achievement. We therefore designed a reflective goal-setting study to learn more about developers' goals and strategies to improve or maintain good habits at work. In our study, 52 professional software developers self-reflected about their work on a daily basis during two to three weeks, which resulted in a rich set of work habit goals and actionable strategies that developers pursue at work. We also found that purposeful, continuous self-reflection not only increases developers' awareness about productive and unproductive work habits (84.5 percent), but also leads to positive self-improvements that increase developer productivity and well-being (79.6 percent). We discuss how tools could support developers with a better trade-off between the cost and value of workplace self-reflection and increase long-term engagement.

A software system's design determines many of its properties, such as maintainability and performance. An understanding of design is needed to maintain system properties as changes to the system occur. Unfortunately, many systems do not have up-to-date design documentation and approaches that have been developed to recover design often focus on how a system works by extracting structural and behaviour information rather than information about the desired design properties, such as robustness or performance. In this paper, we explore whether it is possible to automatically locate where design is discussed in on-line developer discussions. We investigate and introduce a classifier that can locate paragraphs in pull request discussions that pertain to design with an average AUC score of 0.87. We show that this classifier, when applied to projects on which it was not trained, agrees with the identification of design points by humans with an average AUC score of 0.79. We describe how this classifier could be used as the basis of tools to improve such tasks as reviewing code and implementing new features.

Adding an ability for a system to learn inherently adds uncertainty into the system. Given the rising popularity of incorporating machine learning into systems, we wondered how the addition alters software development practices. We performed a mixture of qualitative and quantitative studies with 14 interviewees and 342 survey respondents from 26 countries across four continents to elicit significant differences between the development of machine learning systems and the development of non-machine-learning systems. Our study uncovers significant differences in various aspects of software engineering (e.g., requirements, design, testing, and process) and work characteristics (e.g., skill variety, problem solving and task identity). Based on our findings, we highlight future research directions and provide recommendations for practitioners.

To complete a software development task, a software developer often consults artifacts which mostly consist of natural language text, such as API documentation, bug reports, and Q&A forums. Not all information within these artifacts is relevant to a developer's current task, forcing them to filter through large amounts of irrelevant information, a frustrating and time-consuming activity. Since failing to locate relevant information may lead developers to incorrect or incomplete solutions, many approaches attempt to automatically extract relevant information from natural language artifacts. However, existing approaches are able to identify relevant text only for certain types of tasks and artifacts. To explore how these limitations could be relaxed, we conducted a controlled experiment in which we asked 20 software developers to examine 20 natural language artifacts consisting of 1,874 sentences and highlight the text they considered relevant to six software development tasks. Although the 2,463 distinct highlights participants created indicate variability in the perceived relevance of the text, the information considered key to completing the tasks was consistent. We observe consistency in the text using frame semantics, an approach that captures the key meaning of sentences, suggesting that frame semantics can be used in the future to automatically identify task-relevant information in natural language artifacts.

Brian Randell described software engineering as "the multi-person development of multi-version programs". David Parnas expressed that this "pithy phrase implies everything that differentiates software engineering from other programming" (Parnas, 2011). How does current software engineering research compare against this definition? Is there too much focus currently on research into problems and techniques more associated with programming than software engineering? Are there opportunities to use Randell's description of software engineering to guide the community to new research directions? In this extended abstract, I motivate the keynote, which explores these questions and discusses how a consideration of the development streams used by multiple individuals to produce multiple versions of software opens up new avenues for impactful software engineering research.

A software developer works on many tasks per day, frequently switching between these tasks back and forth. This constant churn of tasks makes it difficult for a developer to know the specifics of when they worked on what task, complicating task resumption, planning, retrospection, and reporting activities. In a first step towards an automated aid to this issue, we introduce a new approach to help identify the topic of work during an information seeking task --- one of the most common types of tasks that software developers face --- that is based on capturing the contents of the developer's active window at regular intervals and creating a vector representation of key information the developer viewed. To evaluate our approach, we created a data set with multiple developers working on the same set of six information seeking tasks that we also make available for other researchers to investigate similar approaches. Our analysis shows that our approach enables: 1) segments of a developer's work to be automatically associated with a task from a known set of tasks with average accuracy of 70.6%, and 2) a word cloud describing a segment of work that a developer can use to recognize a task with average accuracy of 67.9%.

Code context models consist of source code elements and their relations relevant to a development task. Prior research showed that making code context models explicit in software tools can benefit software development practices, e.g., code navigation and searching. However, little focus has been put on how to proactively form code context models. In this paper, we explore the proactive formation of code context models based on the topological patterns of code elements from interaction histories for a project. Specifically, we first learn abstract topological patterns based on the stereotype roles of code elements, rather than on specific code elements; we then leverage the learned patterns to predict the code context models for a given task by graph pattern matching. To determine the effectiveness of this approach, we applied the approach to interaction histories stored for the Eclipse Mylyn open source project. We found that our approach achieves maximum F-measures of 0.67, 0.33 and 0.21 for 1-step, 2-step and 3-step predictions, respectively. The most similar approach to ours is Suade, which supports 1-step prediction only. In comparison to this existing work, our approach predicts code context models with significantly higher F-measure (0.57 over 0.23 on average). The results demonstrate the value of integrating historical and structural approaches to form more accurate code context models.

It is not uncommon to hear laments about how long it takes to build software systems and how often, once built, those systems fail to meet the needs and desires of users. Given that attention has been paid to how we build large software systems for over fifty years, you might wonder why we have not figured out how to build the systems people want in a reasonable amount of time. To put the problems into perspective, fifty years is half the life-span of a Galapagos turtle and many software systems may be amongst the most complex systems ever built by humans. In that light, perhaps it is not surprising that we have not figured it all out. In this talk, I will explore what productivity means to software developers, how we might track the value that is delivered in software produced by developers and how we might begin to think about measuring the productive delivery of effective software.

Developers frequently discuss aspects of the systems they are developing online. The comments they post to discussions form a rich information source about the system. Intention mining, a process introduced by Di Sorbo et al., classifies sentences in developer discussions to enable further analysis. As one example of use, intention mining has been used to help build various recommenders for software developers. The technique introduced by Di Sorbo et al. to categorize sentences is based on linguistic patterns derived from two projects. The limited number of data sources used in this earlier work introduces questions about the comprehensiveness of intention categories and whether the linguistic patterns used to identify the categories are generalizable to developer discussion recorded in other kinds of software artifacts (e.g., issue reports). To assess the comprehensiveness of the previously identified intention categories and the generalizability of the linguistic patterns for category identification, we manually created a new dataset, categorizing 5,408 sentences from issue reports of four projects in GitHub. Based on this manual effort, we refined the previous categories. We assess Di Sorbo et al.'s patterns on this dataset, finding that the accuracy rate achieved is low (0.31). To address the deficiencies of Di Sorbo et al.'s patterns, we propose and investigate a convolution neural network (CNN)-based approach to automatically classify sentences into different categories of intentions. Our approach optimizes CNN by integrating batch normalization to accelerate the training speed, and an automatic hyperparameter tuning approach to tune appropriate hyperparameters of CNN. Our approach achieves an accuracy of 0.84 on the new dataset, improving Di Sorbo et al.'s approach by 171 percent. We also apply our approach to improve an automated software engineering task, in which we use our proposed approach to rectify misclassified issue reports, thus reducing the bias introduced by such data to other studies. A case study on four open source projects with 2,076 issue reports shows that our approach achieves an average AUC score of 0.687, which improves other baselines by at least 16 percent.

When contributing code to a software system, developers are often confronted with the hard task of understanding and adhering to the system's design. This task is often made more difficult by the lack of explicit design information. Often, recorded design information occurs only embedded in discussions between developers. If this design information could be identified automatically and put into a form useful to developers, many development tasks could be eased, such as directing questions that arise during code review, tracking design changes that might affect desired system qualities, and helping developers understand why the code is as it is. In this paper, we take an initial step towards this goal, considering how design information appears in pull request discussions and manually categorizing 275 paragraphs from those discussions that contain design information to learn about what kinds of design topics are discussed.

The development of a software system requires the orchestration of many different people using many different tools. Despite the need for a developer who is performing a task to understand the context in which that task is undertaken, the tools we imagine, build and provide to support software developers are typically isolated. Instead of the tools helping a developer work within the appropriate context, it is the developer who must bring the context to the tools. In this talk, I will argue that the lack of context in the software engineering tools we build limits the effectiveness of developers and of our software development practices.

All kinds of software projects, whether open or closed source, rely on open source components. Repositories that serve open source components to organizations, such as the Central Repository and npmjs.org, report billions of requests per year. Despite the widespread reliance of projects on open source components, little is known about the social interactions that occur between developers of a project using a component and developers of the component itself. In this paper, we investigate the social interactions that occur for 5,133 pairs of projects, from two different communities (Java and Ruby) representing user projects that depend on a component project. We consider such questions as how often are there social interactions when a component is used? When do the social interactions occur? And, why do social interactions occur? From our investigation, we observed that social interactions typically occur after a component has been chosen for use and relied upon. When social interactions occur, they most frequently begin with creating issues or feature requests. We also found that the more use a component receives, the less likely it is that developers of project using the component will interact with the component project, and when those interactions occur, they will be shorter in duration. Our results provide insight into how socio-technical interactions occur beyond the level of an individual or small group of projects previously studied by others and identify the need for a new model of socio-technical congruence for dependencies between, instead of within, projects.

We advocate for a paradigm shift in supporting the information needs of developers, centered around the concept of automated on-demand developer documentation. Currently, developer information needs are fulfilled by asking experts or consulting documentation. Unfortunately, traditional documentation practices are inefficient because of, among others, the manual nature of its creation and the gap between the creators and consumers. We discuss the major challenges we face in realizing such a paradigm shift, highlight existing research that can be leveraged to this end, and promote opportunities for increased convergence in research on software documentation.

Software provided under open source licenses is widely used, from forming high-profile stand-alone applications (e.g., Mozilla Firefox) to being embedded in commercial offerings (e.g., network routers). Despite the high frequency of use of open source licenses, there has been little work about whether software developers understand the open source licenses they use. To our knowledge, only one survey has been conducted, which focused on which licenses developers choose and when they encounter problems with licensing open source software. To help fill the gap of whether or not developers understand the open source licenses they use, we conducted a survey that posed development scenarios involving three popular open source licenses (GNU GPL 3.0, GNU LGPL 3.0 and MPL 2.0) both alone and in combination. The 375 respondents to the survey, who were largely developers, gave answers consistent with those of a legal expert's opinion in 62% of 42 cases. Although developers clearly understood cases involving one license, they struggled when multiple licenses were involved. An analysis of the quantitative and qualitative results of the study indicate a need for tool support to help guide developers in understanding this critical information attached to software components.

One way to improve the productivity of knowledge workers is to increase their self-awareness about productivity at work through self-monitoring. Yet, little is known about expectations of, the experience with, and the impact of self-monitoring in the workplace. To address this gap, we studied software developers, as one community of knowledge workers. We used an iterative, user-feedback-driven development approach (N=20) and a survey (N=413) to infer design elements for workplace self-monitoring, which we then implemented as a technology probe called WorkAnalytics. We field-tested these design elements during a three-week study with software development professionals (N=43). Based on the results of the field study, we present design recommendations for self-monitoring in the workplace, such as using experience sampling to increase the awareness about work and to create richer insights, the need for a large variety of different metrics to retrospect about work, and that actionable insights, enriched with benchmarking data from co-workers, are likely needed to foster productive behavior change and improve collaboration at work. Our work can serve as a starting point for researchers and practitioners to build self-monitoring tools for the workplace.

Many software development organizations strive to enhance the productivity of their developers. All too often, efforts aimed at improving developer productivity are undertaken without knowledge about how developers spend their time at work and how it influences their own perception of productivity. To fill in this gap, we deployed a monitoring application at 20 computers of professional software developers from four companies for an average of 11 full work day in situ. Corroborating earlier findings, we found that developers spend their time on a wide variety of activities and switch regularly between them, resulting in highly fragmented work. Our findings extend beyond existing research in that we correlate developers' work habits with perceived productivity and also show productivity is a personal matter. Although productivity is personal, developers can be roughly grouped into morning, low-at-lunch and afternoon people. A stepwise linear regression per participant revealed that more user input is most often associated with a positive, and emails, planned meetings and work unrelated websites with a negative perception of productivity. We discuss opportunities of our findings, the potential to predict high and low productivity and suggest design approaches to create better tool support for planning developers' work day and improving their personal productivity.

The availability of open source software projects has created an enormous opportunity for software engineering research. However, this availability requires that researchers judiciously select an appropriate set of evaluation targets and properly document this rationale. After all, the choice of targets may have a significant effect on evaluation.

Software developers use issues as a means to describe a range of activities to be undertaken on a software system, including features to be added and defects that require fixing. When creating issues, software developers expend manual effort to specify relationships between issues, such as one issue blocking another or one issue being a sub-task of another. In particular, developers use a variety of relationships to express how work is to be broken down on a project. To better understand how software developers use work breakdown relationships between issues, we manually coded a sample of work breakdown relationships from three open source systems. We report on our findings and describe how the recognition of work breakdown relationships opens up new ways to improve software development techniques.

The work to be performed on open source systems, whether feature developments or defects, is typically described as an issue (or bug). Developers self-select bugs from the many open bugs in a repository when they wish to perform work on the system. This paper evaluates a recommender, called NextBug, that considers the textual similarity of bug descriptions to predict bugs that require handling of similar code fragments. First, we evaluate this recommender using 69 projects in the Mozilla ecosystem. We show that for detecting similar bugs, a technique that considers just the bug components and short descriptions perform just as well as a more complex technique that considers other features. Second, we report a field study where we monitored the bugs fixed for Mozilla during a week. We sent mails to the developers who fixed these bugs, asking whether they would consider working on the recommendations provided by NextBug, 39 developers (59%) stated that they would consider working on these recommendations, 44 developers (67%) also expressed interest in seeing the recommendations in their bug tracking system.

Despite an abundance of commands to make tasks easier to perform, the users of feature-rich applications, such as development environments, use only a fraction of the commands available. Earlier work has shown that command recommendation -- in which, given the command usage history of a set of users, the objective is to predict a command that is likely useful for the user to learn -- can improve the usage of a range of commands available within such applications. In this paper, we present a new algorithm, CoDis, which is built upon three hypotheses. First, we hypothesize that in feature-rich applications there exists co-occurrence patterns between commands. Second, we hypothesize that users of feature-rich applications have prevalent discovery patterns. Finally, we hypothesize that users need different recommendations based on the time elapsed between their last activity and the time of recommendation. We show on data submitted by many users of an integrated development environment (Eclipse) that CoDis outperforms existing approaches: compared to ADAGRAD, the best performing baseline, it achieves an improvement of 10.22% in recall, for a top-N recommendation task (N = 20).

Knowing the impact in real settings of a software development approach is beneficial to both the industry and the research community. In this paper, we report on a field study we conducted at General Motors with the intent of understanding whether the organization was achieving some of the intended benefits of introducing a model-driven approach to software engineering. This study involved both observations and interviews. We found that several factors are still limiting the productivity increase claimed by MDE.

It has long been desired to build software systems predominantly through the composition of existing software components. The need for such a production model is growing given the increasing use and reliance on software for almost everything we interact with from toasters to airplanes. For some kinds of systems, we have come a long way towards meeting the production via composition through the use of libraries, frameworks and plugin architectures. But, for other systems that require tight integrations of components produced by different suppliers, we are not yet able to reliably engineer a software supply chain. In this talk, I will outline some achievements in software supply chains and describe some of the challenges that need to be met to productively provide the systems of the future.

Turnover is the phenomenon of continuous influx and retreat of human resources in a team. Despite being well-studied in many settings, turnover has not been characterized for open-source software projects. We study the source code repositories of five open-source projects to characterize patterns of turnover and to determine the effects of turnover on software quality. We define the base concepts of both external and internal turnover, which are the mobility of developers in and out of a project, and the mobility of developers inside a project, respectively. We provide a qualitative analysis of turnover patterns. We also found, in a quantitative analysis, that the activity of external newcomers negatively impact software quality.

Persuasive technology to motivate healthy behavior is a growing area of research within HCI and ubiquitous computing. The emergence of commercial wearable devices for tracking health- and fitness-related activities arguably represents the first widespread adoption of dedicated ubiquitous persuasive technology. The recent ubiquity of commercial systems allows us to learn about their value and use in truly "in the wild" contexts and understand how practices evolve over long-term, naturalistic use. We present a study with 30 participants who had adopted wearable activity-tracking devices of their own volition and had continued to use them for between 3 and 54 months. The findings, which both support and contrast with those of previous research, paint a picture of the evolving benefits and practices surrounding these emerging technologies over long periods of use. They also serve as the basis for design implications for personal informatics technologies for long-term health and fitness support.

Design is often raised in the literature as important to attaining various properties and characteristics in a software system. At least for open-source projects, it can be hard to find evidence of ongoing design work in the technical artifacts produced as part of the development. Although developers usually do not produce specific design documents, they do communicate about design in different ways. In this paper, we provide quantitative evidence that developers address design through discussions in commits, issues, and pull requests. To achieve this, we built a discussions' classifier and automatically labeled 102,122 discussions from 77 projects. Based on this data, we make four observations about the projects: i) on average, 25% of the discussions in a project are about design; ii) on average, 26% of developers contribute to at least one design discussion; iii) only 1% of the developers contribute to more than 15% of the discussions in a project; and iv) these few developers who contribute to a broad range of design discussions are also the top committers in a project.

The better the software development community becomes at creating software, the more software the world seems to demand. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In both studies, we found that developers perceive their days as productive when they complete many or big tasks without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices.

Although software development involves making numerous decisions amongst alternatives, the design and implementation choices made typically become invisible; what a developer sees in the project's artifacts are the end result of all of the decisions. What if, instead, all of the choices made were tracked and it was easy for a developer to revisit a point where a decision was made and choose another alternative? What if the development environment could detect and suggest alternative choices? What if it was easy and low-cost to try another path? We explore the idea of speculative reprogramming that could support a what-if environment for the programming stages of software development.

As a software system evolves, the system's codebase constantly changes, making it difficult for developers to answer such questions as who is knowledgeable about particular parts of the code or who needs to know about changes made. In this article, we show that an externalized model of a developer's individual knowledge of code can make it easier for developers to answer such questions. We introduce a degree-of-knowledge model that computes automatically, for each source-code element in a codebase, a real value that represents a developer's knowledge of that element based on a developer's authorship and interaction data. We present evidence that shows that both authorship and interaction data of the code are important in characterizing a developer's knowledge of code. We report on the usage of our model in case studies on expert finding, knowledge transfer, and identifying changes of interest. We show that our model improves upon an existing expertise-finding approach and can accurately identify changes for which a developer should likely be aware. We discuss how our model may provide a starting point for knowledge transfer but that more refinement is needed. Finally, we discuss the robustness of the model across multiple development sites.

No abstract available.

Software developers access bug reports in a project's bug repository to help with a number of different tasks, including understanding how previous changes have been made and understanding multiple aspects of particular defects. A developer's interaction with existing bug reports often requires perusing a substantial amount of text. In this article, we investigate whether it is possible to summarize bug reports automatically so that developers can perform their tasks by consulting shorter summaries instead of entire bug reports. We investigated whether existing conversation-based automated summarizers are applicable to bug reports and found that the quality of generated summaries is similar to summaries produced for e-mail threads and other conversations. We also trained a summarizer on a bug report corpus. This summarizer produces summaries that are statistically better than summaries produced by existing conversation-based generators. To determine if automatically produced bug report summaries can help a developer with their work, we conducted a task-based evaluation that considered the use of summaries for bug report duplicate detection tasks. We found that summaries helped the study participants save time, that there was no evidence that accuracy degraded when summaries were used and that most participants preferred working with summaries to working with original bug reports.

When a developer works on code that is shared with other developers, she needs to know why the code has been changed in particular ways to avoid reintroducing bugs. A developer looking at a code change may have access to a short commit message or a link to a bug report which may provide detailed information about how the code changed but which often lacks information about what motivated the change. This motivational information can sometimes be found by piecing together information from a set of relevant project documents, but few developers have the time to find and read the right documentation. We propose the use of multi-document summarization techniques to generate a concise natural language description of why code changed so that a developer can choose the right course of action.

The web is an important source of development-related resources, such as code examples, tutorials, and API documentation. Yet existing development environments are largely disconnected from these resources. In this work, we explore how to provide useful web page recommendations to developers by focusing on the problem of refinding web pages that a developer has previously used. We present the results of a study about developer browsing activity in which we found that 13.7% of developers visits to code-related pages are revisits and that only a small fraction (7.4%) of these were initiated through a low-cost mechanism, such as a bookmark. To assist with code-related revisits, we introduce Reverb, a tool which recommends previously visited web pages that pertain to the code visible in the developer's editor. Through a field study, we found that, on average, Reverb can recommend a useful web page in 51% of revisitation cases.

The emergence of usable unit testing frameworks (e.g., JUnit for Java code) and unit test generators (e.g., CodePro for Java code) make it easier to create more comprehensive unit testing suites for applications. Unfortunately, test code, especially generated test code, can be difficult to comprehend. In this paper, we propose generating human-oriented summaries of test cases. We suggest an initial approach based on a static analysis of the source code of the test cases. Our goal is to help improve a human's ability to quickly comprehend unit test cases so that appropriate decisions can be made about where to place effort when dealing with large unit test suites.

Businesses and consumers all want more software faster. The seemingly ever-increasing demand for more software suggests the need to not only increase production capabilities but also to produce more with the resources available for production. In other words, software development productivity needs to increase. But what is software development productivity anyway? In this talk, I will explore various ways in which productivity, both in general and for software development, has been characterized and will explore ways in which mining software repository information can help accelerate both software development productivity and innovation.

Software developers interact with the development environments they use by issuing commands that execute various programming tools, from source code formatters to build tools. However, developers often only use a small subset of the commands offered by modern development environments, reducing their overall development fluency. In this paper, we use several existing command recommender algorithms to suggest new commands to developers based on their existing command usage history, and also introduce several new algorithms. By running these algorithms on data submitted by several thousand Eclipse users, we describe two studies that explore the feasibility of automatically recommending commands to software developers. The results suggest that, while recommendation is more difficult in development environments than in other domains, it is still feasible to automatically recommend commands to developers based on their usage history, and that using patterns of past discovery is a useful way to do so.

Finding relevant information within the vast amount of information exchanged via feeds is difficult. Previous research into this problem has largely focused on recommending relevant information based on topicality. By not considering individual and situational factors these approaches fall short. Through a formative, interview-based study, we explored how five software developers determined relevancy of items in two kinds of project news feeds. We identified four factors that the developers used to help determine relevancy and found that placement of items in source code and team contexts can ease the determination of relevancy.

Computer users rely on software tools to work effectively and efficiently, but it is difficult for users to be aware of all the tools that might be useful to them. While there are several potential technical solutions to this difficulty, we know little about social solutions, such as one user telling a peer about a tool. To explore these social solutions in one particular domain, we describe a series of interviews with 18 programmers in industry that explore how tool discovery takes place. These interviews provide a rich set of qualitative data that give us detailed insights into how programmers discover tools. One finding was that, while programmers believe that discovery from peers is effective, they actually discover tools from peers relatively infrequently. Another finding was that programmers can effectively discover tools from their peers both in a co-located and remote settings. We describe several implications of our findings, such as that discovery from peers can be enhanced by improving programmers' ability to communicate openly and concisely about tools.

The better we meet the interest of our community, the better we can help bringing ourselves up-to-date with the latest and greatest in and around software engineering. To this purpose, ICSE 2011 for the first time featured technical briefings, an all-day venue for communicating the state of topics related to software engineering, thus providing an exchange of ideas as well as an introduction to the main conference itself.

When performing a software change task, programmers expend substantial effort investigating a system's code base to find and understand just the code that is pertinent to a task-at-hand. A particularly difficult kind of code to handle during these tasks is crosscutting concern code. To help programmers handle such code, we introduce an automated approach that produces a natural language summary that describes both what the concern is and how the concern is implemented. We describe our approach and present the results of an experiment in which programmers were able to perform change tasks more efficiently and more easily with generated concern summaries than without.

Software developers often confront questions such as "Why was the code implemented this way"? To answer such questions, developers make use of information in a software system's bug and source repositories. In this paper, we consider two user interfaces for helping a developer explore information from such repositories. One user interface, from Holmes and Begel's Deep Intellisense tool, exposes historical information across several integrated views, favouring exploration from a single code element to all of that element's historical information. The second user interface, in a tool called Rationalizer that we introduce in this paper, integrates historical information into the source code editor, favouring exploration from a particular code line to its immediate history. We introduce a model to express how software repository information is connected and use this model to compare the two interfaces. Through a lab experiment, we found that our model can help predict which interface is helpful for a particular kind of historical question. We also found deficiencies in the interfaces that hindered users in the exploration of historical information. These results can help inform tool developers who are presenting historical information either directly from or mined from software repositories.

A key collaborative hub for many software development projects is the bug report repository. Although its use can improve the software development process in a number of ways, reports added to the repository need to be triaged. A triager determines if a report is meaningful. Meaningful reports are then organized for integration into the project's development process. To assist triagers with their work, this article presents a machine learning approach to create recommenders that assist with a variety of decisions aimed at streamlining the development process. The recommenders created with this approach are accurate; for instance, recommenders for which developer to assign a report that we have created using this approach have a precision between 70% and 98% over five open source projects. As the configuration of a recommender for a particular project can require substantial effort and be time consuming, we also present an approach to assist the configuration of such recommenders that significantly lowers the cost of putting a recommender in place for a project. We show that recommenders for which developer should fix a bug can be quickly configured with this approach and that the configured recommenders are within 15% precision of hand-tuned developer recommenders.

Each day, a software developer needs to answer a variety of questions that require the integration of different kinds of project information. Currently, answering these questions, such as “What have my co-workers been doing?”, is tedious, and sometimes impossible, because the only support available requires the developer to manually link and traverse the information step-by-step. Through interviews with eleven professional developers, we identified 78 questions developers want to ask, but for which support is lacking. We introduce an information fragment model (and prototype tool) that automates the composition of different kinds of information and that allows developers to easily choose how to display the composed information. In a study, 18 professional developers used the prototype tool to answer eight of the 78 questions. All developers were able to easily use the prototype to successfully answer 94 % of questions in a mean time of 2.3 minutes per question.

The size and high rate of change of source code comprising a software system make it difficult for software developers to keep up with who on the team knows about particular parts of the code. Existing approaches to this problem are based solely on authorship of code. In this paper, we present data from two professional software development teams to show that both authorship and interaction information about how a developer interacts with the code are important in characterizing a developer's knowledge of code. We introduce the degree-of-knowledge model that computes automatically a real value for each source code element based on both authorship and interaction information. We show that the degree-of-knowledge model can provide better results than an existing expertise finding approach and also report on case studies of the use of the model to support knowledge transfer and to identify changes of interest.

Many software artifacts are created, maintained and evolved as part of a software development project. As software developers work on a project, they interact with existing project artifacts, performing such activities as reading previously filed bug reports in search of duplicate reports. These activities often require a developer to peruse a substantial amount of text. In this paper, we investigate whether it is possible to summarize software artifacts automatically and effectively so that developers could consult smaller summaries instead of entire artifacts. To provide focus to our investigation, we consider the generation of summaries for bug reports. We found that existing conversation-based generators can produce better results than random generators and that a generator trained specifically on bug reports can perform statistically better than existing conversation-based generators. We demonstrate that humans also find these generated summaries reasonable indicating that summaries might be used effectively for many tasks.

The four papers in this special section are extended versions of selected papers from the 16th ACM International Symposium on the Foundations of Software Engineering, held in Atlanta, Georgia, 11-13 November 2008.

Systematically improving the efficiency of programmers requires understanding what activities occur during programming, which activities are inefficient and then assessing languages, tools and processes proposed to improve the situation. Conducting the experiments required to support a systematic approach is difficult for many reasons, including the lack of availability of experienced programmers and the common belief that individual programmer effectiveness varies greatly. In this paper, we investigate whether generic activity traces of how a programmer interacts with a development environment can help bridge between results gathered in the lab with how programming occurs in the field. We describe the kinds of information that can be gleaned from activity traces, consider whether positive indication of a behaviour seen in the lab translates to data collected from the field, and discuss challenges with gathering appropriate data and with using gathered data appropriately.

Different flavours of recommendation systems have been proposed to help software developers perform software evolution tasks. A number of these recommendation systems are based on changesets. When changeset information is used, recommendations are based on only the end result of the activity undertaken to complete a task. In this paper, we report on an investigation that compared how recommendations based on changesets compare to recommendations based on interactions collected as a programmer performed the task that resulted in a changeset. To provide a common basis for the comparison, our investigation considered how bug reports considered similar based on changeset information compare to bug reports considered similar based on interaction information. We found that there is no direct relationship between the bug reports found similar with the different methods, suggesting that each comparison methods captures a different aspect of the problem.

The productivity of software developers is under constant attack due to a continual inundation of information: source code is easier and easier to traverse and to find, email inboxes are stuffed to capacity, RSS feeds and tweets provide a continual stream of technology updates, and so on. To enable software developers to work more effectively, tools are often introduced that provide even more information. The effect of more and more tools producing more and more information is placing developers into overload. To combat this overload, we have been building approaches rooted in structure and inspired by human memory models. As an example, the Mylyn project packages and makes available the structure that emerges from how a programmer works in an episodic-memory inspired interface. Programmers working with Mylyn see only the information they need for a task and can recall past task information with a simple click. We have shown in a field study that Mylyn makes programmers more productive; the half a million programmers now using Mylyn seem to agree. In this talk, I will describe the overload faced by programmers today and discuss several approaches we have developed to attack the problem, some of which may also pertain beyond the domain of software development.

Programmers seek to answer questions as they investigate the functioning of a software system, such as "which execution path is being taken in this case?" Programmers attempt to answer these questions, which we call conceptual queries, using a variety of tools. Each type of tool typically highlights one kind of information about the system, such as static structural information or control-flow information. Unfortunately for the programmer, the tools seldom directly answer the programmer's conceptual queries. Instead, the programmer must piece together results from different tools to determine an answer to the initial query. At best, this process is time consuming and at worst, this process can lead to data overload and disorientation.

We report on an exploratory study we conducted to investigate what kind of diagrammatic tool support, if any, is desired by programmers. The study involved 19 professional programmers working at three different companies. We found that the study participants desire a wide range of information content in diagrams, which would change depending upon the particular context of use. Meeting these needs may require flexible, adaptive and responsive diagramming tool support.

There is a growing consensus that crosscutting concerns harm code quality. An example of a crosscutting concern is a functional requirement whose implementation is distributed across multiple software modules. We asked the question, "How much does the amount that a concern is crosscutting affect the number of defects in a program?" We conducted three extensive case studies to help answer this question. All three studies revealed a moderate to strong statistically significant correlation between the degree of scattering and the number of defects. This paper describes the experimental framework we developed to conduct the studies, the metrics we adopted and developed to measure the degree of scattering, the studies we performed, the efforts we undertook to remove experimental and other biases, and the results we obtained. In the process, we have formulated a theory that explains why increased scattering might lead to increased defects.

Little is known about the specific kinds of questions programmers ask when evolving a code base and how well existing tools support those questions. To better support the activity of programming, answers are needed to three broad research questions: 1) What does a programmer need to know about a code base when evolving a software system? 2) How does a programmer go about finding that information? 3) How well do existing tools support programmers in answering those questions? We undertook two qualitative studies of programmers performing change tasks to provide answers to these questions. In this paper, we report on an analysis of the data from these two user studies. This paper makes three key contributions. The first contribution is a catalog of 44 types of questions programmers ask during software evolution tasks. The second contribution is a description of the observed behavior around answering those questions. The third contribution is a description of how existing deployed and proposed tools do, and do not, support answering programmers' questions.

During the flight of Apollo 13, an oxygen tank blew up threatening the lives of the astronauts. When it happened, James Lovell Jr. told the Houston control center, "Hey Houston, we 've had a problem here." Although not as catastrophic, software developers productivity is being threatened by an inundation of information: source code is easier and easier to traverse and to find, email inboxes are stuffed to capacity, RSS feeds provide a continual stream of technology updates, and so on. To enable software developers to work more effectively, software engineering researchers often deliver tools, which produce even more information. The effect of more and more tools producing more and more information is placing developers into overload. It would be reasonable to here a software developer utter, "Houston: We are in overload"! In this talk, I will discuss the quagmire in which software developers are finding themselves, discuss how they are coping based on data collected from the activity of developers, and suggest ways of helping developers regain control.

Programmers need tools to help explore large software systems when performing software evolution tasks. A variety of tools have been created to improve the effectiveness of such exploration. The usefulness of these tools has been argued largely on the basis of case studies, small narrowly-focussed experiments, or non-human-based experiments. In this paper, we report on a more rigorously controlled study of three specialized software exploration tools in which professional programmers used the tools to plan complex change tasks to a medium-sized code base. We found that the tools had little apparent effect; the effects observed instead appear to be dominated by individual styles and strategies of the programmers and characteristics of the tasks. In addition to presenting the results of the study, this paper introduces the use of two experimental evaluation aids: the NASA task load index (TLX) for assessing task difficulty and distance profiles for assessing the to which programmers remain on-track.

The practice of software development can likely be improved if an externalized model of each programmer's knowledge of a particular code base is available. Some tools already assume a useful form of such a model can be created from data collected during development, such as expertise recommenders that use information about who has changed each file to suggest who might answer questions about particular parts of a system. In this paper, we report on an empirical study that investigates whether a programmer's activity can be used to build a model of what a programmer knows about a code base. In this study, nineteen professional Java programmers completed a series of questionnaires about the code on which they were working. These questionnaires were generated automatically and asked about program elements a programmer had worked with frequently and recently and ones that he had not. We found that a degree of interest model based on this frequency and recency of interaction can often indicate the parts of the code base for which the programmer has knowledge. We also determined a number of factors that may be used to improve the model, such as authorship of program elements, the role of elements, and the task being performed.

Becoming a quality software developer requires practice under the guidance of an expert mentor. Unfortunately, in most academic environments, there are not enough experts to provide any significant design mentoring for software engineering students. To address this problem, we present a collaborative software design tool intended to maximize an instructor's ability to mentor a group of students. Students use the system to create software designs for a given set of requirements. While they work, students receive automated feedback regarding common design mistakes. The system then provides support and guidance for students to manually critique each other's work. Students can view and learn from the design approaches taken by other students, as well as the critiques associated with them. We have tried this approach in software engineering classes with some positive results. We believe that this collaborative and partially automated approach can significantly improve the quality of software design education when few mentors are available.

A software modification task often addresses several concerns . A concern is anything a stakeholder may want to consider as a conceptual unit, including features, nonfunctional requirements, and design idioms. In many cases, the source code implementing a concern is not encapsulated in a single programming language module, and is instead scattered and tangled throughout a system. Inadequate separation of concerns increases the difficulty of evolving software in a correct and cost-effective manner. To make it easier to modify concerns that are not well modularized, we propose an approach in which the implementation of concerns is documented in artifacts, called concern graphs. Concern graphs are abstract models that describe which parts of the source code are relevant to different concerns. We present a formal model for concern graphs and the tool support we developed to enable software developers to create and use concern graphs during software evolution tasks. We report on five empirical studies, providing evidence that concern graphs support views and operations that facilitate the task of modifying the code implementing scattered concerns, are cost-effective to create and use, and robust enough to be used with different versions of a software system.

Open source development projects typically support an open bug repository to which both developers and users can report bugs. The reports that appear in this repository must be triaged to determine if the report is one which requires attention and if it is, which developer will be assigned the responsibility of resolving the report. Large open source developments are burdened by the rate at which new bug reports appear in the bug repository. In this paper, we present a semi-automated approach intended to ease one part of this process, the assignment of reports to a developer. Our approach applies a machine learning algorithm to the open bug repository to learn the kinds of reports each developer resolves. When a new report arrives, the classifier produced by the machine learning technique suggests a small number of developers suitable to resolve the report. With this approach, we have reached precision levels of 57% and 64% on the Eclipse and Firefox development projects respectively. We have also applied our approach to the gcc open source development with less positive results. We describe the conditions under which the approach is applicable and also report on the lessons we learned about applying machine learning to repositories used in open source development.

When working on a large software system, a programmer typically spends an inordinate amount of time sifting through thousands of artifacts to find just the subset of information needed to complete an assigned task. All too often, before completing the task the programmer must switch to working on a different task. These task switches waste time as the programmer must repeatedly find and identify the information relevant to the task-at-hand. In this paper, we present a mechanism that captures, models, and persists the elements and relations relevant to a task. We show how our task context model reduces information overload and focuses a programmer's work by filtering and ranking the information presented by the development environment. A task context is created by monitoring a programmer's activity and extracting the structural relationships of program artifacts. Operations on task contexts integrate with development environment features, such as structure display, search, and change management. We have validated our approach with a longitudinal field study of Mylar, our implementation of task context for the Eclipse development environment. We report a statistically significant improvement in the productivity of 16 industry programmers who voluntarily used Mylar for their daily work.

Though many tools are available to help programmers working on change tasks, and several studies have been conducted to understand how programmers comprehend systems, little is known about the specific kinds of questions programmers ask when evolving a code base. To fill this gap we conducted two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a medium-sized code base. The other study involved industrial programmers working on their own change tasks on code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on howthey go about discovering that information. Based on this analysis we catalog and categorize 44 different kinds of questions asked by our participants. We also describe important context for how those questions were answered by our participants, including their use of tools.

We report on a field study about how software developers experience disorientation when using the Eclipse Java integrated development environment. We analyzed the data using the theory of visual momentum, identifying three factors that may lead to disorientation: the absence of connecting navigation context during program exploration, thrashing between displays to view necessary pieces of code, and the pursuit of sometimes unrelated subtasks

When coding to an application programming interface (API), developers often encounter difficulties, unsure of which class to subclass, which objects to instantiate, and which methods to call. Example source code that demonstrates the use of the API can help developers make progress on their task. This paper describes an approach to provide such examples in which the structure of the source code that the developer is writing is matched heuristically to a repository of source code that uses the API. The structural context needed to query the repository is extracted automatically from the code, freeing the developer from learning a query language or from writing their code in a particular style. The repository is generated automatically from existing applications, avoiding the need for handcrafted examples. We demonstrate that the approach is effective, efficient, and more reliable than traditional alternatives through four empirical studies

When coding to a framework, developers often become stuck, unsure of which class to subclass, which objects to instantiate and which methods to call. Example code that demonstrates the use of the framework can help developers make progress on their task. In this paper, we describe an approach for locating relevant code in an example repository that is based on heuristically matching the structure of the code under development to the example code. Our tool improves on existing approaches in two ways. First, the structural context needed to query the repository is extracted automatically from the code, freeing the developer from learning a query language or from writing their code in a particular style. Second, the repository can be generated easily from existing applications. We demonstrate the utility of this approach by reporting on a case study involving two subjects completing four programming tasks within the Eclipse integrated development environment framework.

Using the application programming interfaces (API) of large software systems requires developers to understand details about the interfaces that are often not explicitly defined. However, documentation about the API is often incomplete or out of date. Existing systems that make use of the API provide a form of implicit information on how to use that code. Manually searching through existing projects to find relevant source code is tedious and time consuming. We have created the Strathcona Example.Recommendation Tool to assist developers in finding relevant fragments of code, or examples, of an API's use. These examples can be used by developers to provide insight on how they are supposed to interact with the API.

It has been broadly assumed that code clones are inherently bad and that eliminating clones by refactoring would solve the problems of code clones. To investigate the validity of this assumption, we developed a formal definition of clone evolution and built a clone genealogy tool that automatically extracts the history of code clones from a source code repository. Using our tool we extracted clone genealogy information for two Java open source projects and analyzed their evolution. Our study contradicts some conventional wisdom about clones. In particular, refactoring may not always improve software with respect to clones for two reasons. First, many code clones exist in the system for only a short time; extensive refactoring of such short-lived clones may not be worthwhile if they are likely diverge from one another very soon. Second, many clones, especially long-lived clones that have changed consistently with other elements in the same group, are not easily refactorable due to programming language limitations. These insights show that refactoring will not help in dealing with some types of clones and open up opportunities for complementary clone maintenance tools that target these other classes of clones.

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.

Prior to performing a software change task, developers must discover and understand the subset of the system relevant to the task. Since the behavior exhibited by individual developers when investigating a software system is influenced by intuition, experience, and skill, there is often significant variability in developer effectiveness. To understand the factors that contribute to effective program investigation behavior, we conducted a study of five developers performing a change task on a medium-size open source system. We isolated the factors related to effective program investigation behavior by performing a detailed qualitative analysis of the program investigation behavior of successful and unsuccessful developers. We report on these factors as a set of detailed observations, such as evidence of the phenomenon of inattention blindness by developers skimming source code. In general, our results support the intuitive notion that a methodical and structured approach to program investigation is the most effective.

Software developers are often faced with modification tasks that involve source which is spread across a code base. Some dependencies between source code, such as those between source code written in different languages, are difficult to determine using existing static and dynamic analyses. To augment existing analyses and to help developers identify relevant source code during a modification task, we have developed an approach that applies data mining techniques to determine change patterns - sets of files that were changed together frequently in the past - from the change history of the code base. Our hypothesis is that the change patterns can be used to recommend potentially relevant source code to a developer performing a modification task. We show that this approach can reveal valuable dependencies by applying the approach to the Eclipse and Mozilla open source projects and by evaluating the predictability and interestingness of the recommendations produced for actual modification tasks on these systems.

A developer attempting to evolve a system in which design patterns have been applied can benefit from knowing which code implements which design pattern. For instance, the developer may be able to understand the purpose, or to assess the flexibility of the code, more quickly. The degree to which the developer benefits depends upon their understanding of the pattern. Achieving an in-depth understanding of even a simple pattern can be difficult as pattern descriptions span several pages of text, and discuss interrelated design concepts and choices. To enable a developer to effectively trace the design goals associated with a pattern to and from source, we have developed the Design Pattern Rationale Graph (DPRG) approach and associated tool. A DPRG makes explicit the relationships between design concepts in a design pattern, provides a graphical representation of the design pattern text, and supports the linking of those concepts to implementing code. In this paper, we introduce the DPRG approach and tool, and present case studies to show that a DPRG can, at low-cost, help a developer identify design goals in a pattern, and can improve a developer's confidence about how those goals are realized in a code base.

A newcomer to a software project must typically come up-to-speed on a large, varied amount of information about the project before becoming productive. Assimilating this information in the open-source context is difficult because a newcomer cannot rely on the mentoring approach that is commonly used in traditional software developments. To help a newcomer to an open-source project become productive faster, we propose Hipikat, a tool that forms an implicit group memory from the information stored in a project's archives, and that recommends artifacts from the archives that are relevant to a task that a newcomer is trying to perform. To investigate this approach, we have instantiated the Hipikat tool for the Eclipse open-source project. In this paper we describe the Hipikat tool, we report on a qualitative study conducted with a Hipikat mock-up on a medium-sized in-house project, and we report on a case study in which Hipikat recommendations were evaluated for a task on Eclipse.

Developers working on existing programs repeatedly have to address concerns, or aspects, that are not well modularized in the source code comprising a system. In such cases, a developer has to first locate the implementation of the concern in the source code comprising the system, and then document the concern sufficiently to be able to understand it and perform the actual change task.

When performing a program evolution task, developers typically spend a significant amount of effort investigating and reinvestigating source code. To reduce this effort, we propose a technique to automatically infer the essence of program investigation activities as a set of concern descriptions. The concern descriptions produced by our technique list methods and fields of importance in the context of the investigation of an object-oriented system. A developer can rely on this information to perform the change task at hand, or at a later stage for a change that involves the same concerns. The technique involves applying an algorithm to a transcript of a program investigation session. The transcript lists which pieces of source code were accessed by a developer when investigating a program and how the different pieces of code were accessed. We applied the technique to data obtained from program investigation activities for five subjects involved in two different program evolution tasks. The results show that relevant concerns can be identified with a manageable level of noise.

Exception-handling mechanisms in modern programming languages provide a means to help software developers build robust applications by separating the normal control flow of a program from the control flow of the program under exceptional situations. Separating the exceptional structure from the code associated with normal operations bears some consequences. One consequence is that developers wishing to improve the robustness of a program must figure out which exceptions, if any, can flow to a point in the program. Unfortunately, in large programs, this exceptional control flow can be difficult, if not impossible, to determine.In this article, we present a model that encapsulates the minimal concepts necessary for a developer to determine exception flow for object-oriented languages that define exceptions as objects. Using these concepts, we describe why exception-flow information is needed to build and evolve robust programs. We then describe Jex, a static analysis tool we have developed to provide exception-flow information for Java systems based on this model. The Jex tool provides a view of the actual exception types that might arise at different program points and of the handlers that are present. Use of this tool on a collection of Java library and application source code demonstrates that the approach can be helpful to support both local and global improvements to the exception-handling structure of a system.

Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graph representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.

Many modification tasks on an existing software system result in changes to code that crosscuts the system's structure. Making these changes is difficult because a developer must understand large parts of the system, and must reason about how the modification will interact with the existing behaviour. Typically, developers make these kinds of changes using an ad-hoc approach with tools that help in gaining some understanding of the existing system, but that do not provide any specific support for reasoning about, implementing, or analyzing just that part of the system related to the modification. We present the behavioural concern modelling (BCM) approach and tool that provide direct support for a systematic approach to modification tasks. This approach enables a developer to create a partial, abstract, grounded behavioural model of a concern(s). By grounded, we mean that the relationship between the model and the code is explicit: A developer describes which code contributes to which parts of the model. The examples we describe use a finite state machine as a model. We show how the approach can help a developer capture a concern, reason about design options, and implement modifications.

Most software systems are inflexible. Reconfiguring a system's modules to add or to delete a feature requires substantial effort. This inflexibility increases the costs of building variants of a system, amongst other problems. New languages and tools that are being developed to provide additional support for separating concerns show promise to help address this problem. However applying these mechanisms requires determining how to enable a feature to be separated from the codebase. We investigate this problem through an exploratory study conducted in the context of two existing systems: gnu.regexp and jFTPd. The study consisted of applying three different separation of concern mechanisms: Hyper/J/sup TM/ AspectJ/sup TM/ and a lightweight, lexically-based approach, to separate features in the two packages. We report on the study, providing contributions in two areas. First, we characterize the effect different mechanisms had on the structure of the codebase. Second, we characterize the restructuring process required to perform the separations. These characterizations can help researchers to elucidate how the mechanisms may be best used, tool developers to design support to aid the separation process, and early adopters to apply the techniques.

The artifacts constituting a software system often drift apart over time. We have developed the software reflexion model technique to help engineers perform various software engineering tasks by exploiting, rather than removing, the drift between design and implementation. More specifically, the technique helps an engineer compare artifacts by summarizing where one artifact (such as a design) is consistent with and inconsistent with another artifact (such as source). The technique can be applied to help a software engineer evolve a structural mental model of a system to the point that it is "good enough" to be used for reasoning about a task at hand. The software reflexion model technique has been applied to support a variety of tasks, including design conformance, change assessment, and an experimental reengineering of the million-lines-of-code Microsoft Excel product. We provide a formal characterization of the reflexion model technique, discuss practical aspects of the approach, relate experiences of applying the approach and tools, and place the technique into the context of related work.

Past ICSE attendees will recognize—with pleasure, we hope—workshops that have been successful in previous years. Indeed, we have tried to balance the program between workshops based on novel and promising ideas, with those strongly continuing the work started in previous ICSEs. In two cases, the program also includes workshops that already have some tradition, but are associated with ICSE for the first time: the ISAW workshop (4th edition) and the DSV-IS workshop (7th edition).

Exception handling mechanisms are intended to help developers build robust systems. Although an exception handling mechanism provides a basis for structuring source code dealing with unusual situations, little information is available to help guide a developer in the appropriate application of the mechanism. In our experience, this lack of guidance leads to complex exception structures. In this paper, we reflect upon our experiences using the Java exception handling mechanism. Based on these experiences, we discuss two issues we believe underlie the difficulties encountered: exceptions are a global design problem, and exception sources are often dif-ficult to predict in advance. We then describe a design approach, based on work by Litke for Ada programs, which we have used to simplify exception structure in existing Java programs.

Software systems should consist of simple, conceptually clean software components interacting along narrow, well-defined paths. All too often, this is not reality: complex components end up interacting for reasons unrelated to the functionality they provide. We refer to knowledge within a component that is not conceptually required for the individual behaviour of that component as extraneous embedded knowledge (EEK). EEK creeps into a system in many forms, including dependences upon particular names and the passing of extraneous parameters. This paper proposes the use of implicit context as a means for reducing EEK in systems by combining a mechanism to reflect upon what has happened in a system, through queries on the call history, with a mechanism for altering calls to and from a component. We demonstrate the benefits of implicit context by describing its use to reduce EEK in the Java™ Swing library.

The principle of separation of concerns has long been used by software engineers to manage the complexity of software system development.Programming languages help software engineers explicitly maintain the separation of some concerns in code.As another step towards increasing the scope of concerns that can be captured cleanly within the code, Kiczales and colleagues have introduced aspect-oriented programming.In aspect-oriented programming, explicit language support is provided to help modularize design decisions that cross-cut a functionally-decomposed program.Aspect-oriented programming is intended to make it easier to reason about, develop, and maintain certain kinds of application code.To investigate these claims, we conducted two exploratory experiments that considered the impact of aspect-oriented programming, as found in AspectJ version 0.1, on two common programming activities: debugging and change.Our experimental results provide insights into the usefulness and usability of aspect-oriented programming.Our results also raise questions about the characteristics of the interface between aspects and functionallydecomposed core code that are necessary to accrue programming benefits.Most notably, the separation provided by aspect-oriented programming seems most helpful when the interface is narrow (i.e., the separation is more complete); partial separation does not necessarily provide partial benefit.

The Advanced Teaching and Learning Academic Server (Atlas) is a software system that supports web-based learning. Students can register for courses, and can navigate through personalized views of course material. Atlas has been built according to Sun Microsystem's Java™ Servlet specification using Xerox PARC's aspect-oriented programming support called Aspect™. Since aspect-oriented programming is still in its infancy, little experience with employing this paradigm is currently available. In this paper, we start filling this gap by describing the aspects we used in Atlas and by discussing the effect of aspects on our object-oriented development practices. We describe some rules and policies that we employed to achieve our goals of maintainability and modifiability, and introduce a straightforward notation to express the design of aspects. Although we faced some obstacles along the way, this combination of technology helped us build a fast, well-structured system in a reasonable amount of time.

Determining whether a new software development technique is useful and usable is a challenging taste. Various flavors of empirical study may be used to help with this task, including surveys, case studies, and experiments. Little guidance is available within the software engineering community to help choose among these alternatives when assessing a new and evolving software development technique within some cost bounds. We faced this challenge when assessing a new programming technique called aspect-oriented programming. To assess the technique, we chose to apply both a case study approach and a series of four experiments because we wanted to understand and characterize the kinds of information that each approach might provide. We describe and critique the evaluation methods we employed, and discuss the lessons we have learned. These lessons are applicable to other researchers attempting to assess new programming techniques that are in an early stage of development.

Many tools have been built to analyze source code. Most of these tools do not adequately support reengineering activities because they do not allow a software engineer to simultaneously perform queries about both the existing and the desired source structure. This paper introduces the conceptual module approach that overcomes this limitation. A conceptual module is a set of lines of source that are treated as a logical unit. We show how the approach simplifies the gathering of source information for reengineering tasks, and describe how a tool to support the approach was built as a front-end to existing source analysis tools.

Dynamic information collected as a software system executes can help software engineers perform some tasks on a system more effectively. To interpret the sizable amount of data generated from a system's execution, engineers require tool support. We have developed an off-line, flexible approach for visualizing the operation of an object-oriented system at the architectural level. This approach complements and extends existing profiling and visualization approaches available to engineers attempting to utilize dynamic information. In this paper, we describe the technique and discuss preliminary qualitative studies into its usefulness and usability. These studies were undertaken in the context of performance tuning tasks.

Informally, a call graph represents calls between entities in a given program. The call graphs that compilers compute to determine the applicability of an optimization must typically be conservative: a call may be omitted only if it can never occur in any execution of the program. Numerous software engineering tools also extract call graphs with the expectation that they will help software engineers increase their understanding of a program. The requirements placed on software engineering tools that compute call graphs are typically more relaxed than for compilers. For example, some false negatives—calls that can in fact take place in some execution of the program, but which are omitted from the call graph—may be acceptable, depending on the understanding task at hand. In this article, we empirically show a consequence of this spectrum of requirements by comparing the C call graphs extracted from three software systems (mapmaker, mosaic, and gcc) by nine tools (cflow, cawk, CIA, Field, GCT, Imagix, LSME, Mawk, and Rigiparse). A quantitative analysis of the call graphs extracted for each system shows considerable variation, a result that is counterintuitive to many experienced software engineers. A qualitative analysis of these results reveals a number of reasons for this variation: differing treatments of macros, function pointers, input formats, etc. The fundamental problem is not that variances among the graphs extracted by different tools exist, but that software engineers have little sense of the dimensions of approximation in any particular call graph. In this article, we describe and discuss the study, sketch a design space for static call graph extractors, and discuss the impact of our study on practitioners, tool developers, and researchers. Although this article considers only one kind of information, call graphs, many of the observations also apply to static extractors of other kinds of information, such as inheritance structures, file dependences, and references to global variables.

Designing reusable software modules can be extremely difficult.The design must be balanced between being general enough to address the needs of a wide range of clients and being focused enough to truly satisfy the requirements of each specific client One area where it can be particularly difficult to strike this balance is in the implementation strategy of the module.The problem is that generalpurpose implementation strategies, tuned for a wide range of clients, aren't necessarily optimal for each specific client-this is especially an issue for modules that are intended to be reusable and yet provide high-performance.An examination of existing software systems shows that an increasingly important technique for handling this problem is to design the module's interface in such a way that the client can assist or participate in the selection of the module's implementation strategy.We call this approach open implementation.When designing the interface to a module that allows its clients some control over its implementation strategy, it is important to retain, as much as possible, the advantages of traditional closed implementation modules.This paper explores issues in the design of interfaces to open implementation modules.We identify key design choices, and present guidelines for deciding which choices are likely to work best in particular situations.

Software engineers maintaining an existing software system often depend on the mechanized extraction of information from system artifacts. Some useful kinds of information—source models—are well known: call graphs, file dependences, etc. Predicting every kind of source model that a software engineer may need is impossible. We have developed a lightweight approach for generating flexible and tolerant source model extractors from lexical specifications. The approach is lightweight in that the specifications are relatively small and easy to write. It is flexible in that there are few constraints on the kinds of artifacts from which source models are extracted (e.g., we can extract from source code, structured data files, documentation, etc.). It is tolerant in that there are few constraints on the condition of the artifacts. For example, we can extract from source that cannot necessarily be compiled. Our approach extended the kinds of source models that can be easily produced from lexical information while avoiding the constraints and brittleness of most parser-based approaches. We have developed tools to support this approach and applied the tools to the extraction of a number of different source models (file dependences, event interactions, call graphs) from a variety of system artifacts (C, C++, CLOS, Eiffel. TCL, structured data). We discuss our approach and describe its application to extract source models not available using existing systems; for example, we compute the implicitly-invokes relation over Field tools. We compare and contrast our approach to the conventional lexical and syntactic approaches of generating source models.

Reverse engineers depend on the automatic extract ion of information from source code.Some useful kinds of information+ource models-are wellknown: call graphs, file dependence, etc. Predicting every kind of source model that a reverse engi-

article Software reflexion models: bridging the gap between source and high-level models Share on Authors: Gail C. Murphy Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , David Notkin Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WA Dept. of Computer Science & Engineering, University of Washington, Box 352350, Seattle WAView Profile , Kevin Sullivan Dept. of Computer Science, University of Virginia, Charlottesville VA Dept. of Computer Science, University of Virginia, Charlottesville VAView Profile Authors Info & Claims ACM SIGSOFT Software Engineering NotesVolume 20Issue 4Oct. 1995 pp 18–28https://doi.org/10.1145/222132.222136Published:01 October 1995 305citation2,070DownloadsMetricsTotal Citations305Total Downloads2,070Last 12 Months74Last 6 weeks13 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access