Negative experiences in diverse software development teams have the potential to turn off minority participants from future team-based software development activity. We examine the use of brainstorming as one concrete team processes that may be used to improve the satisfaction of minority developers when working in a group. Situating our study in time-intensive hackathon-like environments where engagement of all team members is particularly crucial, we use a combination of survey and interview data to test our propositions. We find that brainstorming strategies are particularly effective for team members who identify as minorities, and support satisfaction with both the process and outcomes of teamwork through different mechanisms.

Hackathons are events where people who are not normally collocated converge for a few days to write code together. Hackathons, it seems, are everywhere. We know that long- term collocation helps advance technical work and facilitate enduring interpersonal relationships, but can similar benefits come from brief, hackathon-style collocation? How do participants spend their time preparing, working face-to- face, and following through these brief encounters? Do the activities participants select suggest a tradeoff between the social and technical benefits of collocation? We present results from a multiple-case study that suggest the way that hackathon-style collocation advances technical work varies across technical domain, community structure, and expertise of participants. Building social ties, in contrast, seems relatively constant across hackathons. Results from different hackathon team formation strategies suggest a tradeoff between advancing technical work and building social ties. Our findings have implications for technology support that needs to be in place for hackathons and for understanding the role of brief interludes of collocation in loosely-coupled, geographically distributed work.

Sharing scientific data, software, and instruments is becoming increasingly common as science moves toward large-scale, distributed collaborations. Sharing these resources requires extra work to make them generally useful. Although we know much about the extra work associated with sharing data, we know little about the work associated with sharing contributions to software, even though software is of vital importance to nearly every scientific result. This paper presents a qualitative, interview-based study of the extra work that developers and end users of scientific software undertake. Our findings indicate that they conduct a rich set of extra work around community management, code maintenance, education and training, developer-user interaction, and foreseeing user needs. We identify several conditions under which they are likely to do this work, as well as design principles that can facilitate it. Our results have important implications for future empirical studies as well as funding policy.

Community code engagements -- short-term, intensive software development events -- are used by some scientific communities to create new software features and promote community building. But there is as yet little empirical support for their effectiveness. This paper presents a qualitative study of two types of community code engagements: Google Summer of Code (GSoC) and hackathons. We investigated the range of outcomes these engagements produce and the underlying practices that lead to these outcomes. In GSoC, the vision and experience of core members of the community influence project selection, and the intensive mentoring process facilitates creation of strong ties. Most GSoC projects result in stable features. The agenda setting phase of hackathons reveals high priority issues perceived by the community. Social events among the relatively large numbers of participants over brief engagements tend to create weak ties. Most hackathons result in prototypes rather than finished tools. We discuss themes and tradeoffs that suggest directions for future empirical work around designing community code engagements.

Trust remains a challenge in globally distributed development teams. In order to investigate how trust plays out in this context, we conducted a qualitative study of 5 multi-national IT organizations. We interviewed 58 individuals across 10 countries and made two principal findings. First, study participants described trust in terms of their expectations of their colleagues. These expectations fell into one of three dimensions: that socially correct behavior will persist, that team members possess technical competency, and that individuals will demonstrate concern for others. Second, our study participants described trust as a dynamic process, with phases including formation, dissolution, adjustment and restoration. We provide new insights into these dimensions and phases of trust within distributed teams which extend existing literature. Our study also provides guidelines on effective practices within distributed teams in addition to providing implications for the extension of software engineering and collaboration tools.

We seek to provide design principles for software tools intended to support the development of trust in distributed teams. As such, we present a "design space" for such tools that consists of three elements: trust factors, collaborative traces, and visual representations. Trust factors are aspects of work shown in the research literature to influence one's perceived trustworthiness of their team members. Collaborative traces are representations of past and current work done by team members manipulating project artifacts. Collaborative traces provide information about a trust factor. Visual representations consist of a set of visual abstractions of the collaborative traces arranged in a layout that provides users with the ability to formulate accurate perceptions of their team members' trustworthiness with respect to a particular trust factor. Because the eventual goal of this research is to produce visual interfaces that support the development of trust, we apply elements from the design space to the design of three example visualizations. We conclude by assessing the value of the model and outlining future work.

We sought to understand the role that Web 2.0 technologies play in supporting the development of trust in globally distributed development teams. We found the use of Web 2.0 technologies to be minimal, with less than 25% of our participants reporting using them and many reporting the disadvantages of adopting them. In response, we sought to understand the factors that led to the use and non-use of these technologies in distributed development teams. We adopted a mix of qualitative and quantitative methods to analyze data collected from 61 interviewees representing all common roles in systems development. We discovered six factors that influenced the use and non-use of Web 2.0 technology. We present a proclivity model to frame our findings as well as our conclusions about the interrelationships between the results of our qualitative and quantitative analyses. We also present implications for the design of collaboration tools, which could lead to greater support and usage by distributed developers.

In software development projects, dependencies between developers arise from dependencies in the source-code they write. This observation emerged in our own field studies and the related literature. In response, we created Ariadne, a visualization tool that allows end-users to explore socio-technical relationships in software development projects.

Ariadne is a novel visualization tool that allows end users to explore the socio-technical relationships in software development projects. Essentially the visualization is a variant of a social network graph. It is based on the observation that dependencies between software components create dependencies between the developers implementing those components. This relationship emerged in our own and other researcherspsila field studies of software projects. Large software development projects require management of dependencies by managers and developers to ensure the smooth coordination of work. We sought to evaluate our visualization to assess its utility. Although we had some informal trials with potential end users, we sought a deeper analysis before further refinement of the tool and evaluation on a larger scale. Usability inspection methods provided one potential avenue. Moreover, such inspection methods yield a kind of rationale not directly derived from human subjects evaluations. We report on the application of these inspection methods and discuss the implications of their results in the context of usability evaluations for visual interfaces.

One of the reasons large-scale software development is difficult is the number of dependencies that software engineers face. These dependencies create a need for communication and coordination that requires continuous effort by developers. Empirical studies, including our own, suggest that technical dependencies among software components create social dependencies among the software developers implementing those components. Based on this observation, we developed Ariadne, a plug-in for Eclipse. Ariadne analyzes software projects for dependencies and collects authorship information about projects relying on configuration management repositories. Ariadne can "translate" technical dependencies among components into social dependencies among developers. We have created visualizations to convey dependency information and the presence of coordination problems identified in our previous work. We believe the information conveyed in the visualizations will prove useful for software developers.