| Coordination in large-scale software teams | | BIBA | Full-Text | 1-7 | |
| Andrew Begel; Nachiappan Nagappan; Christopher Poile; Lucas Layman | |||
| Large-scale software development requires coordination within and between very large engineering teams which may be located in different buildings, on different company campuses, and in different time zones. From a survey answered by 775 Microsoft software engineers, we learned how work was coordinated within and between teams and how engineers felt about their success at these tasks. The respondents revealed that the most common objects of coordination are schedules and features, not code or interfaces, and that more communication and personal contact worked better to make interactions between teams go more smoothly.expand | |||
| Bridging knowledge distribution -- The role of knowledge brokers in distributed software development teams | | BIBA | Full-Text | 8-11 | |
| Alexander Boden; Gabriela Avram | |||
| Software development requires the handling of complex and context specific knowledge to be successful. Hence, efficient knowledge management (KM) counts amongst the most important challenges for any software project, but especially for small enterprises working with distributed teams. One important topic for KM in distributed teams is the role of "bridges" enacted by people who become boundary spanners and facilitate the exchange of knowledge between the sites. In our paper we present empirical findings related to such bridges in the context of two small companies with offshore sites. In doing so, we concentrate on the particular roles these knowledge brokers play in the distributed development practices. We show how small software companies rely on the commitment of particular team members and informal knowledge management practices. The paper concludes with a number of open questions to be addressed by future studies.expand | |||
| Automatically identifying that distributed programmers are stuck | | BIBA | Full-Text | 12 | |
| Jason Carter; Prasun Dewan | |||
| We hypothesize that it is useful and possible to automatically identify that distributed programmers are stuck by extending existing software development environments using a general architecture. | |||
| Audio-video recording of ad hoc software development team interactions | | BIBA | Full-Text | 13-21 | |
| Sebastien Cherry; Pierre N. Robillard | |||
| Ad hoc interactions characterize the natural behaviors observed in any teamwork situation. Our objective is to find out how these interactions are related to the roles team mates play. Observations on the phenomenon are based on audio-video recordings of software development team interactions occurring in a large software development organization with a highly standardized software development process in place. Detailed observations were recorded on the activities of four of the twelve members of the development team. Thirty-five hours of audio-video recordings were analyzed, in which a total of 404 face-to-face ad hoc collaborative interactions were observed. The results provided a quantitative demonstration of the impact of a newcomer, a "guru", and a project manager on the team dynamics. This study, although conducted in a specific professional environment, can provide useful information for a better understanding of the face-to-face communication needs of a software development team.expand | |||
| Designing software for unfamiliar domains | | BIBA | Full-Text | 22 | |
| Parmit K. Chilana; Andrew J. Ko; Jacob O. Wobbrock | |||
| In recent years, software has become indispensable in complex domains such as science, engineering, biomedicine, and finance. Unfortunately, software developers and user researchers, who are usually experts in programming and Human-Computer Interaction (HCI) methods, respectively, often find that the insight needed to design for complex domains only comes with years of domain experience. How can everyone on a software design team acquire just enough knowledge to design effective software, especially user interfaces, without having to become domain experts? We are performing a series of studies to investigate this question, with the ultimate goal of designing tools to help software teams better capture, manage and explore domain knowledge.expand | |||
| Personalities, cultures and software modeling: Questions, scenarios and research directions | | BIBA | Full-Text | 23-31 | |
| Americo B. Cunha; Alberto G. Canen; Miriam A. M. Capretz | |||
| Several evolutions in software engineering (SE) relate to the development of a reliable communication process among the project stakeholders. The models resulting from these improvements are the key instruments of communication in SE. There are studies that relate several problems in SE to user-engineers interactions during the modeling process. In addition to the usual challenges related to the technological issues of software modeling, new problems have appeared due to the presence of a multinational workforce. Specifically, people with distinct cultural identities must work together and, independently from their personal values and beliefs, they must develop common objectives. Consequently, this paper argues that the personality and cultural identity of project team members might be unconsciously affecting the SE process in a much greater way than is currently believed. Moreover, a research framework for investigating the influence of individual identities in the modelling techniques can present new perspectives for improving SE outcomes.expand | |||
| A qualitative study on project landscapes | | BIBA | Full-Text | 32-35 | |
| Barthelemy Dagenais; Harold Ossher; Rachel K. E. Bellamy; Martin P. Robillard; Jacqueline P. de Vries | |||
| When developers join a project, they find themselves in a new project landscape and must orient themselves quickly. To investigate the nature of this project landscape, and how we could help newcomers orient themselves, we have started an exploratory study using grounded theory. We primarily collect our data by interviewing experienced developers who recently joined ongoing projects. We are already seeing some patterns emerge. For example, it seems that newcomers find it more important to be able to experiment with the system early on than to have up-to-date and complete documentation.expand | |||
| Why are software projects moving from centralized to decentralized version control systems? | | BIBA | Full-Text | 36-39 | |
| Brian de Alwis; Jonathan Sillito | |||
| Version control systems are essential for co-ordinating work on a software project. A number of open- and closed-source projects are proposing to move, or have already moved, their source code repositories from a centralized version control system (CVCS) to a decentralized version control system (DVCS). In this paper we summarize the differences between a CVCS and a DVCS, and describe some of the rationales and perceived benefits offered by projects to justify the transition.expand | |||
| Writing and Reading Software Documentation: How the development process may affect understanding | | BIBA | Full-Text | 40-47 | |
| Remco C. de Boer; Hans van Vliet | |||
| The effectiveness of documentation within a development process is determined by the way in which the intentions of the authors correspond to the expectations of the potential readers. Ideally, the members of a development team share a certain understanding of (the role of) the different types of documentation. However, since one's expectations of a document are personal, and part of a tacitly formed mental model, we can expect different levels of shared understanding between different development team members. We elicited and analyzed the mental models of software documentation from eight members of a single development team. We found indeed different levels of shared understanding between different people. To our surprise, the levels of shared understanding within the team appear closely tied to the development process employed. From Conway's law we know that an organization's structure is mirrored in the structure of the software that the organization produces. Our findings suggest that the organization's development process may likewise be mirrored in the extent to which a development team shares a common frame of reference. Hence, the development process followed may have implications for the effectiveness with which development knowledge can be shared through software documentation.expand | |||
| Distributed side-by-side programming | | BIBA | Full-Text | 48-55 | |
| Prasun Dewan; Puneet Agarwal; Gautam Shroff; Rajesh Hegde | |||
| Recent work has proposed a variation of pair programming called side-by-side programming, wherein two programmers, sitting next to each other and using different workstations, work together on the same task. We have defined a distributed approximation of this idea and implemented it in both a compiled and interpretive environment. Our experiments with these implementations provide several new preliminary results regarding different aspects of (distributed) side-by-side programming.expand | |||
| Enabling and enhancing collaborations between software development organizations and independent test agencies | | BIBA | Full-Text | 56-59 | |
| James A. Jones; Mark Grechanik; Andre van der Hoek | |||
| While the use of independent test agencies is on the rise -- currently estimated to be a $25B marketplace -- there are a number of challenges to successful collaboration between these agencies and their client software development organizations. These agencies offer independent verification of software, skilled testing experts, and economic advantages that arise from differential global labor rates. However, these benefits are often offset by difficulties in effectively integrating the outsourced testing into software development practice. We conducted extensive discussions with test managers and engineers at software development organizations. This position paper presents the findings of these discussions that identify key difficulties of integrating independent test agencies into software development practice, and it describes our position on how these findings can be addressed.expand | |||
| Knowledge management in practice: The case of agile software development | | BIBA | Full-Text | 60-65 | |
| Meira Levy; Orit Hazzan | |||
| Knowledge is considered as the main competitive asset of the organization. One of the knowledge management (KM) cornerstones is improving productivity by effective knowledge sharing and transfer. However, from the game theory perspective, the main constraint is that people tend not to collaborate in uncertainty conditions, when collaborative behavior is not guaranteed, and sharing knowledge is time- and effort-consuming. Therefore, KM must be a practical aspect of the general organizational culture. Specifically, software development is a knowledge-intensive activity and its success depends heavily on the developers' knowledge and experience. In this presentation we highlight how the agile approach initiates a culture change that is in line with the culture change needed for a KM initiative. We discuss KM enablers that are embedded in the agile software engineering approach, and illustrate how collaborating processes and knowledge transparency can weaken the dilemmas people face and lead to better knowledge extraction and sharing.expand | |||
| Supporting agile team composition: A prototype tool for identifying personality (In)compatibilities | | BIBA | Full-Text | 66-73 | |
| Sherlock Licorish; Anne Philpott; Stephen G. MacDonell | |||
| Extensive work in the behavioral sciences tells us that team composition is a complex activity in many disciplines, given the variations inherent across individuals' personalities. The composition of teams to undertake software development is subject to this same complexity. Furthermore, the building of a team to undertake agile software development may be particularly challenging, given the inclusive yet fluid nature of teams in this context. We describe here the development and preliminary evaluation of a prototype tool intended to assist software engineers and project managers in forming agile teams, utilizing information concerning members' personalities as input to this process. Initial assessment of the tool's capabilities by agile development practitioners suggests that it would be of value in supporting the team composition activity in real projects.expand | |||
| The role of blogging in generating a software product vision | | BIBA | Full-Text | 74-77 | |
| Shelly Park; Frank Maurer | |||
| The core problem with requirements engineering is that often even the customers have no clear idea what they need; they don't know how to express it; or even if they express it really well, what they thought they need wasn't what they really need. Despite having the technical skills and being able to speak the domain language, generating requirements for software developers by the developers is found to be quite a difficult task. We discuss four types of strategies for expressing one's desire for requirements. We analyze how stories turn into consensus.expand | |||
| QUASE -- A quantitative approach to analyze the human aspects of software development projects | | BIBA | Full-Text | 78 | |
| Rafael Prikladnicki | |||
| A manager's most important and most difficult job is to manage people. If software is created by people, the human side of software development is crucial to the success of a project. In this position paper, we argue that a quantitative approach to analyze the human aspects of software development may contribute to a better understanding of different expectations and a better management of people and projects.expand | |||
| Discovering determinants of high volatility software | | BIBA | Full-Text | 79 | |
| Carolyn Seaman; A. Gunes Koru; Sreedevi Sampath | |||
| This topic paper presents a line of research that we are proposing that incorporates, in a very explicit and intentional way, human and organizational aspects in the prediction of troublesome (defect-prone or changeprone or volatile, depending on the environment) software modules. Much previous research in this area tries to identify these modules by looking at their structural characteristics, so that increased effort can be concentrated on those modules in order to reduce future maintenance costs.expand | |||
| Exception handling negligence due to intra-individual goal conflicts | | BIBA | Full-Text | 80-83 | |
| Hina Shah; Mary Jean Harrold | |||
| Despite research to provide support for improving the usage of exception handling in programs, studies show that exception handling is neglected. In previous work, we interviewed novice developers to understand their problems when dealing with exceptions. The results show that these developers gave exception handling low priority and they thought that use of exception handling was forced on them. Thus, developers adopted an ignore-for-now approach for dealing with exceptions. In this paper, we present the results of our investigation of this problem of neglecting exception handling. We conducted a literature study to understand the psychological aspects of the problem that may be affecting the appropriate usage of exception handling in programs. Based on our investigation that was supported by this study, we believe that developers have intra-individual conflicting goals when they are expected to design and code the core functionality as well as the exception handling functionality. We recommend some strategies to address this problem of conflicting goals at academic and industry levels.expand | |||
| An initial investigation of software practitioners' motivation | | BIBA | Full-Text | 84-91 | |
| Helen Sharp; Tracy Hall | |||
| Motivation is one of the most frequently cited causes of software development project failure, reportedly impacting on project productivity, software quality and the overall success of the project. Much of the previous research into software engineers' motivation cites the job itself as the main motivator, yet little research has focused on why software engineers stay in the profession. This paper reports on an empirical investigation with experienced software practitioners which focuses on this issue and compares our findings with existing work. The results show that aspects of 'people' are important in job satisfaction and project choice, while a practitioner's standing in the community is a key influence on whether or not he/she will stay in software engineering; aspects of 'creativity' are mentioned most often as making software development worthwhile. When asked to identify three key elements of motivation, aspects of 'people' were mentioned the most often.expand | |||
| The work of software development as an assemblage of computational practice | | BIBA | Full-Text | 92-95 | |
| Susan Elliott Sim; Marisa Leavitt Cohn; Kavita Philip | |||
| Science and technology studies (STS) is a discipline concerned with examining how social and technological worlds shape each other. In this paper, we argue that STS can be used to study the work of software development as a complex, interacting system of people, organizations, culture, practices, and technology, or in STS terms, an assemblage. We illustrate the application of these ideas to the work of software development, where STS theory directs us towards examining at human-human relations, human-machine relations, and machine-machine relations. We conclude by discussing some of the challenges of applying STS in empirical software engineering.expand | |||
| Taking care of cooperation when evolving socially embedded systems: The PloneMeeting case | | BIBA | Full-Text | 96-103 | |
| Hataichanok Unphon; Yvonne Dittrich; Arnaud Hubaux | |||
| This paper proposes a framework to (i) analyse the contexts of socially embedded systems and (ii) support the understanding of change during their evolutions. Our finding is based on a co-operative project with a government agency developing a partially-automated variability configurator for an open source software product family. By employing our framework, we realised that the way variations and their management are implemented have to accommodate work practices from the use context as well as development practice, and here especially the cooperation within the development team and between users and developers. The empirical evidence has confirmed our understanding of what is relevant when estimating the evolvability of socially embedded systems. We propose to use our framework in architecture-level design and evaluation in order to take these cooperative relationships into account early in the evolution cycle.expand | |||
| Challenges in the user interface design of an IDE tool recommender | | BIBA | Full-Text | 104-107 | |
| Petcharat Viriyakattiyaporn; Gail C. Murphy | |||
| To help software developers work efficiently, integrated development environments (IDE) include many tools. All too often, these developers are unaware of potentially useful tools within these IDEs that might help them complete their work more effectively. To improve both awareness and use of tools within an IDE, we have been developing a recommendation system called Spyglass that recommends tool(s) that might help a developer navigate information available in an IDE more efficiently. When designing such a recommendation system, important considerations are both the content of the recommendations and the form and manner in which those recommendations are made. In this paper, we focus on what we learned about the form and manner of making tool recommendations from a longitudinal user study of Spyglass. These results may be useful to others designing various kinds of recommendation systems for IDEs.expand | |||
| Reporting usability metrics experiences | | BIBA | Full-Text | 108-115 | |
| Jeff Winter; Kari Ronkko; Mats Hellman | |||
| It is often claimed that software development is negatively affected by infrequent, incomplete and inconsistent measurements; improving with the help of metrics is an obvious solution. Software testing provides opportunities for measurement that give organizations insight in to processes. Usability testing is part of the testing area, although it is not a commonly addressed area within software engineering, perhaps because of a split between qualitative and quantitative paradigms. We compare a usability testing framework called UTUM with principles for Software Process Improvement, and find areas of close agreement as well as areas where our work illuminates new characteristics. UTUM is found to be a useful vehicle for improvement in software engineering, dealing as it does with both product and process. Our work emphasises the importance of the neglected area of usability testing. Our experience also illustrates how the metrics have been tailored to act as a boundary object between different disciplines.expand | |||