No abstract

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 longterm 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-toface, 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.

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.

One of the reasons why large-scale software development is difficult is the number of dependencies that software engineers need to face: e.g., dependencies among the software components and among the development tasks. These dependencies create a need for communication and coordination that requires continuous effort by software developers. Empirical studies, including our own, suggest that technical dependencies among software components create social dependencies among the software developers implementing these components. Based on this observation, we developed Ariadne, a Java plug-in for Eclipse. Ariadne analyzes a Java project to identify program dependencies and collects authorship information about the project by connecting to a configuration management repository. Through this process, Ariadne can "translate" technical dependencies among software components into social dependencies among software developers. This paper describes the design of Ariadne, how it identifies technical dependencies among software components, how it extracts information from configuration management systems and, finally, how it translates this into social dependencies. Ariadne's purpose is to create a bridge between technical and social dependencies.

No abstract

Mentoring is one of the most effective pedagogical tools, holding great promise for software engineering education. When done badly, however, it can lead to dysfunctional interpersonal relationships and may turn off mentees from careers in software engineering. In this qualitative interview-based study we examine how socio-technical dimensions of software impact the formation of social ties important for satisfying two goals of mentorship, building technical skill and interpersonal development. We find that mentees working on user facing, interdependent software form a balance of ties that facilitate both goals, while mentees working on non-user facing software mostly form ties important for building technical skill. Work practices that create opportunities for unstructured contact between mentees and community members, such as code review in a mentee cohort, can help to overcome this imbalance. Our findings have important implications for task definition in software engineering e-mentoring program schemes.

No abstract

No abstract