CHASE '18- Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering

Communication and collaboration is a major challenge for large-scale software development. Cognitive and psychological distance between individuals and teams affect this collaboration and can cause communications gaps. We propose a novel method for assessing distance between teams, and explore potential explanations for these distances. In an exploratory case study of the quality assurance department at Axis Communications, we used interactive posters to collect data and obtained a 52% response rate from the 175 test engineers. We identified low psychological distance as an indicator of a company culture with open and frequent communication, and of a team with good social networking skills and well-functioning points of contact. We found that low cognitive distance is an indicator of differences regarding the responsibilities of a team; within the same system and between different types of systems. We also found correlations between psychological and cognitive distance. Large organisations may apply our concept to assess distance between teams, and our finding can be useful in interpreting these distances. Furthermore, our results provide a basis for further research on how the concept of distances can be used to assess collaboration within large organisations.

Education on software startups is taken its first steps. A multidisciplinary and collaborative approach seems to be key to deliver a high quality software startup development program. In this sense, we conducted a study describing the path of 191 students through a startup mobile application development program. Our preliminary results indicate that using Challenge Based Learning methodology combined with agile practices can strengthen students' collaboration and engagement into the process.

Chatbots have rapidly become a mainstay in software development. A range of chatbots contribute regularly to the creation of actual production software. It is somewhat difficult, however, to precisely delineate hype from reality. Questions arise as to what distinguishes a chatbot from an ordinary software tool, what might be desirable properties of chatbots, and where their future may lie. This position paper introduces a starting framework through which we examine the current state of chatbots and identify directions for future work.

Software companies are looking for strategies that allow them to be competitive and stay in the market, these companies must not be limited to create new products, they also need to improve their production and marketing processes. The Software Product Lines (SPL) is a production strategy based on planned reuse that seeks to improve productivity, decreasing the time to market and increasing quality of the products. One of the essential activities in the adoption of this approach and development of a SPL is scoping. The SPL scoping is an interdisciplinary activity that includes different visions such as business, marketing, technical aspects and context issues; therefore, the participation of different people with dissimilar and partial knowledge is a key factor in the SPL Scoping. The diversity of participants is relevant but it is not easy that people with different knowledge and interests interact with each other and agree on the scope of the product line. This paper presents an empirical analysis about the addition of collaborative practices in SPL scoping process. We contrasted the results obtained in SPL scoping when collaborative elements are used in the process, observing the execution and results obtained by two groups that followed two different methods for SPL scoping; a group used the original method and the other group followed the same process but including collaborative elements.

Context: Task interdependence is one of the social characteristics of work design, which has been related by some authors to the level of interaction between team members and their results. In recent years, more research aiming to investigate the interactions between people and teamwork in Software Engineering (SE) has been conducted. However, few of these initiatives have been associated with work design, especially as related to task interdependence in SE. Goal: To investigate the perception of the individuals in a software development team concerning task interdependence and their individual impact on teamwork dynamics. Method: We investigated a development team from a Brazilian software development company. For data collection, interviews were conducted and qualitative coding techniques were used to analyze and synthesize our findings. In addition, we have the support of an analytical framework built at the commencement of our research. Results: Task interdependence increases the need for information sharing and synchronization of tasks, it also favors the creation of an environment conducive to redundancy of knowledge and mutual help, and it is moderated by interpersonal relationships, a sense of belonging, and individual competencies and skills, favoring the generation of better results in software development teams. Conclusion: Task interdependence is an important practice and an essential and impacting factor in teamwork dynamics which can enhance the performance of software development teams.

Onboarding is a critical stage in the tenure of software developers with a project, because meaningful contribution requires familiarity with the codebase. Some software teams employ practices, such as mentoring, to help new developers get accustomed faster. Code review, i.e., the manual inspection of code changes, is an opportunity for sharing knowledge and helping with onboarding.

In this study, we investigate whether and how contributions from developers with low experience in a project do receive a different treatment during code review. We compare reviewers' experience, metrics of reviewers' attention, and change merge rate between changes from newcomers and from more experienced authors in 60 active open source projects. We find that the only phenomenon that is consistent across the vast majority of projects is a lower merge rate for newcomers' changes.

A programming context can be defined as all the relevant information that a developer needs to complete a task. Context comprises information from different sources and programmers interpret the same information differently based on their programming goal. In fact, the same artifact may create a different context when revisited. Context, therefore, by its very nature is a "slippery notion."

To understand how people create context we observed six programmers engaged in exploratory programming and performed a qualitative analysis of their activities. We observe that the interactions with artifacts and a mapping of meaning from those artifacts for a programming activity determines how one creates context.

With improved digital literacy and cheaper data connections, crowdsourcing has become more prevalent. Crowdsourcing tasks such as image tagging, language translation, etc. have contributors with varied skill level. Question and answers, software development/testing and product design are more serious tasks and require expert contributions. With increasing security threats, crowdsourcing in 'security' domain is seen as an upcoming trend. In the survey, opportunities and challenges in crowdsourcing security are analyzed based on a survey conducted with 229 participants. The results provide insights on motivation, quality mechanisms and improvement areas for increased participation. 'Question and Answers' that includes information sharing and 'software development and testing' that includes Bug Bounty are identified as top crowdsourcing tasks by security specialists although they are concerned about security and privacy of information. Among quality attributes analyzed, contributor 'credibility' is identified as a key area of improvement for increased participation in crowdsourcing.

A significant number of studies reported models for competence profiling, measuring capabilities of professionals and recommendation systems for roles within agile software development (ASD). These models coordinated in human resource management within ASD. However, in the light of swift, incremental and iterative nature of ASD practices, designing solutions that easily integrate capability measurements with ongoing project management routines, is an important area for investigation. With the support of interviews, grounded theory procedure and workshops, we identified the aspects valued by our industrial collaborator while allocating professionals to tasks. This information was further utilized towards devising a framework for capability-centric Web tool. This tool provides a one-stop solution for project managers to create projects, keep track of capabilities and execute allocation routines.

¹ Studies about diversity in Software Engineering (SE) are important to understand the disparity occurring nowadays at information technology workplaces. The goal of this work is to analyze the characteristics of diversity in SE and how to adapt SE practices when we have teams with diversity characteristics. We collected data by conducting a Systematic Literature Review (SLR) and semi-structured interviews aiming to identify what impacts of diversity can be observed in software development teams. We found that there are several challenges and barriers encountered in the work environment, and that inclusion and diversity can affect the software development teams positively.

This paper presents a new method of engaging older participants in the process of application and IT solutions development for older adults for emerging IT and tech startups. A new method called SPIRAL (Support for Participant Involvement in Rapid and Agile software development Labs) is proposed which adds both sustainability and flexibility to the development process with older adults. This method is based on the participatory approach and user empowerment of older adults with the aid of a bootstrapped Living Lab concept and it goes beyond well established user-centered and empathic design. SPIRAL provides strategies for direct involvement of older participants in the software development processes from the very early stage to support the agile approach with rapid prototyping, in particular in new and emerging startup environments with limited capabilities, including time, team and resources.

Safety-critical software systems are those whose failure or malfunction could result in casualty and/or serious financial loss. In such systems, safety assurance cases (SACs) are an emerging approach that adopts a proactive strategy to produce structuralized safety justifications and arguments. While SACs are recommended in many software-intensive safety-critical domains, the lack of knowledge regarding the practitioners' perspectives on using SACs hinders effective adoption of this approach. To gain such knowledge, we interviewed nine practitioners and safety experts who focused on safety-critical software systems. In general, our participants found the SAC approach beneficial for communication of safety arguments and management of safety issues in a multidisciplinary setting. The challenges they faced when using SACs were primarily associated with (1) a lack of tool support, (2) insufficient process integration, and (3) scarcity of experienced personnel. To overcome those challenges, our participants suggested tactics that focused on creating direct safety arguments. Process and organizational adjustments are also needed to streamline SAC analysis and creation. Finally, our participants emphasized the importance of knowledge sharing about SACs across software-intensive safety-critical domains.

ROS (Robot Operating System) is an open source community in robotics that is developing standard robotics operating system facilities such as hardware abstraction, low-level device control, communication middleware, and a wide range of software components for robotics functionality. This paper studies the quality assurance practices of the ROS community. We use qualitative methods to understand how ideology, priorities of the community, culture, sustainability, complexity, and adaptability of the community affect the implementation of quality assurance practices. Our analysis suggests that software engineering practices require social and cultural alignment and adaptation to the community particularities to achieve seamless implementation in open source environments. This alignment should be incorporated into the design and implementation of quality assurance practices in open source communities.

Requirement engineering (RE) presents several challenges stemming from the required collaboration and knowledge transfer between analysists, developers and customers. Motivation theories have been used occasionally to analyze and encourage motivation and engagement of stakeholders in RE tasks. In recent years, gamification techniques have been used in software engineering tasks, and in some cases, in RE tasks in order to promote stakeholder engagement. This paper presents a preliminary literature review that was conducted in order to model correlations documented in literature between RE tasks, stakeholder motivation and engagement, and gamification. The preliminary findings show promise for conducting a full systematic literature review (SLR) in order to complete modeling existing evidence-based literature. The SLR and the emergent model will set the grounds for a research agenda toward an exhaustive model that will offer guidance for designing gamified environments for different RE tasks, based on motivational and behavioral factors.

Two main concepts in Agile software development are self-organized teams and direct contact with the customer or Product Owner. Additionally, constant feedback on different levels is considered to be of high importance. With constant feedback, transparency goes hand-in-hand. Compared to traditional software development, Agile approaches have much higher transparency, and this might be a problem for some people. What does it feel like to work in such an Agile team or organization for the individual? How do the software developers, testers or other team members experience this environment of high transparency and continuous feedback? In this paper we focus on a subset of the third Swiss Agile Study from 2016, a nationwide survey about software development, to shed some light on the sociological, cultural and cognitive aspects of Agile teams and their individual member. We found that despite the increased transparency, the majority of the participants reported working in an Agile environment, both on the individual and on the team level, as positive and satisfying. The analysis shows these positive influences have some strong correlations with certain Agile practices and with innovation and business aspects.

This note highlights the importance of investigating diversity aspects in combination in empirical research. It draws on the psychological discourse and suggests why and how software engineering scholars can use the aspect of diversity in all their research endeavors.

In the software engineering industry today, companies primarily conduct their work in teams. To increase organizational productivity, it is thus crucial to know the factors that affect team effectiveness. Two team-related concepts that have gained prominence lately are psychological safety and team norms. Still, few studies exist that explore these in a software engineering context.

Therefore, with the aim of extending the knowledge of these concepts, we examined if psychological safety and team norm clarity associate positively with software developers' self-assessed team performance and job satisfaction, two important elements of effectiveness.

We collected industry survey data from practitioners (N = 217) in 38 development teams working for five different organizations. The result of multiple linear regression analyses indicates that both psychological safety and team norm clarity predict team members' self-assessed performance and job satisfaction. The findings also suggest that clarity of norms is a stronger (30% and 71% stronger) predictor than psychological safety.

This research highlights the need to examine, in more detail, the relationship between social norms and software development. The findings of this study could serve as an empirical baseline for such, future work.

Continuous Software Engineering (CSE)---continuous development and deployment of software---and DevOps---the close cooperation or integration of operations and software development---is about to change how software is developed. Together with the tighter integration of development and operations also with usage this will change coordination and collaboration both between IT professionals and between developers and users. In this short paper, we discuss the CHASE dimension of three core research themes that begin to crystallize in literature. This position paper is intended as a 'call to arms' for the CHASE community to study CSE.

Coordination was early identified as a key challenge in software development, and in particular in large development projects. With the arrival of agile methods and their increasing use also in large-scale projects, this calls for rethinking how the software engineering community addresses coordination. We argue for increasing the focus on coordination in software engineering and describe four directions for research. Focus on these areas can supplement advice given in current development methods with relevant research-based advice.

With the advent of large interactive displays and the increasing ubiquity of touch-enabled devices, digital sketching tools are becoming viable alternatives to classic whiteboards for the design and engineering of software systems. In this paper, we argue that current sketching tools still focus largely on creating sketches as artifacts (mostly, models), rather than recognizing sketches as byproducts of engineers' thought processes as they tackle a broad variety of complex engineering activities. We therefore advocate a more activity-than artifact-oriented view of sketching and propose research on a number of ways in which digital sketching can support cognitively demanding software engineering activities more directly.

Background: Agile teams are supposed to be cross-functional in order to be complete (so they can work without external help). Cross-functionality is also supposed to produce cross-fertilization: Better ideas and solutions, problems prevented or detected earlier, etc. Question: What is motivating or demotivating team members to work in a cross-functional manner? Method: We conceptualize observations from five agile teams (work observations, interviews, group discussion) and from interviews with five agile consultants/coaches by applying Grounded Theory Methodology. Results: The inclination to interact cross functionally is moderated by at least six factors such as perceived inefficiency, a sense of responsibility for one's own functional domain, or the difficulty to find a level of detail that is suitable for the collaboration. Conclusion: Cross-fertilization is harder to get than one might expect and teams need to develop good judgment to succeed at it.

As a software system is iteratively developed, software developers engage in many discussions, often through written forms. Some of these discussions occur on pull requests and include information about the design of the system to which the code in the pull request is being contributed. Although previous work has shown that design is discussed in forums like pull requests, little is known about the form and content of the discussion about design.

In this paper, we report on an in-depth analysis of three pull requests to better understand the form and content of design information in pull request discussions to enable the development of tools to help humans access this information.

Knowledge - of all kinds - is essential to software design. It is well known, however, that most knowledge resides in the developers' heads. Especially when designing at the whiteboard, tool support is minimal, most often non-existent. In this brief research note, we sketch our ongoing research into supporting designers at the whiteboard with proactive knowledge that is collected, earlier, in some (semi-)automatic fashion.

Although many software companies have recently embraced Open Source Software (OSS) initiatives, volunteers (i.e., developers who contribute to OSS in their spare time) still represent a wealthy workforce that have the potential of driving many non-trivial open source projects. Such volunteers face well-known barriers when attempting to contribute to OSS projects. However, what is still unclear is how the problems that volunteers face transcend to the problems that employees (i.e., developers hired by a software company to work on OSS projects) face. In this paper we aim to investigate the differences on the acceptance of patches submitted by volunteers and employees to company-owned OSS projects. We explore different characteristics of the patches submitted to company-owned OSS project, including: the frequency of acceptance and rejection; the total time to review and process a patch, and; whether the changes proposed follow some contribution best practices. We found that volunteers face 26X more rejections than employees. Volunteers have to wait, on average, 11 days to have a patch processed (employees wait 2 days, on average). 92% of the dormant pull-requests (e.g., pull-requests that take too long to be processed) were submitted by employees. Finally, we observed that the best practices that had the patches are most adherent to is "commit messages need to be written in English."

The maintenance and evolution of Free/Libre Open Source Software (FLOSS) projects demand the constant attraction of core developers. In this paper, we report the results of a survey with 52 developers, who recently became core contributors of popular GitHub projects. We reveal their motivations to assume a key role in FLOSS projects (e.g., improving the projects because they are also using it), the project characteristics that most helped in their engagement process (e.g., a friendly community), and the barriers faced by the surveyed core developers (e.g., lack of time of the project leaders). We also compare our results with related studies about others kinds of open source contributors (casual, one-time, and newcomers).