Judith Segal

Ethnographically-informed empirical studies of software practice

Over the past decade we have performed a sustained series of qualitative studies of software development practice, focusing on social factors. Using an ethnographically-informed approach, we have addressed four areas of software practice: software quality management systems, the emergence of object technology, professional end user development and agile development. Several issues have arisen from this experience, including the nature of research questions that such studies can address, the advantages and challenges associated with being a member of the community under study, and how to maintain rigour in data collection. In this paper, we will draw on our studies to illustrate our approach and to discuss these and other issues.

When Software Engineers Met Research Scientists: A Case Study

This paper describes a case study of software engineers developing a library of software components for a group of research scientists, using a traditional, staged, document-led methodology. The case study reveals two problems with the use of the methodology. The first is that it demands an upfront articulation of requirements, whereas the scientists had experience, and hence expectations, of emergent requirements; the second is that the project documentation does not suffice to construct a shared understanding. Reflecting on our case study, we discuss whether combining agile elements with a traditional methodology might have alleviated these problems. We then argue that the rich picture painted by the case study, and the reflections on methodology that it inspires, has a relevance that reaches beyond the original context of the study.

Developing Scientific Software

Not all scientific computing is high-performance computing—the variety of scientific software is huge. Such software might be complex simulation software developed and running on a high-performance computer, or software developed on a PC for embedding into instruments; for manipulating, analyzing or visualizing data or for orchestrating workflows. This special issue provides some flavor of that variety. It also explores the question of how the development of scientific software can be improved.

Software Development Cultures and Cooperation Problems: A Field Study of the Early Stages of Development of Software for a Scientific Community

In earlier work, I identified a particular class of end-user developers, who include scientists and whom I term ‘professional end-user developers’, as being of especial interest. Here, I extend this work by articulating a culture of professional end-user development, and illustrating by means of a field-study how the influence of this culture causes cooperation problems in an inter-disciplinary team developing a software system for a scientific community. My analysis of the field study data is informed by some recent literature on multi-national work cultures. Whilst acknowledging that viewing a scientific development through a lens of software development culture does not give a full picture, I argue that it nonetheless provides deep insights.

The type of evidence produced by empirical software engineers

This paper reports on the research published between the years 1997 and 2003 inclusive in the journal of Empirical Software Engineering, drawing on the taxonomy developed by Glass et al. in [3]. We found that the research was somewhat narrow in topic with about half the papers focusing on measurement/metrics, review and inspection; that researchers were almost as interested in formulating as in evaluating; that hypothesis testing and laboratory experiments dominated evaluations; that research was not very likely to focus on people and extremely unlikely to refer to other disciplines. We discuss our findings in the context of making empirical software engineering more relevant to practitioners.

Some challenges facing software engineers developing software for scientists

In this paper, I discuss two types of challenges facing software engineers as they develop software for scientists. The first type is those challenges that arise from the experience that scientists might have of developing their own software. From this experience, they internalise a model of software development but may not realise the contextual factors which make such a model successful. They thus have expectations and assumptions which prove challenging to software engineers. The second type is those challenges which, while not unique to the development of software for scientists, have especial significance in the context of such development. These include the challenges of ensuring effective user engagement and of developing software for a community.

The nature of evidence in empirical software engineering

In this paper, we argue that the gap between empirical software engineering and software engineering practice might be lessened if more attention were paid to two important aspects of evidence. The first is that evidence from case or field studies of actual software engineering practice are essential in order to understand and inform that practice. The second is that the nature of evidence should fit the purpose to which the evidence is going to be put. One type of evidence is not per se better than another. For example, the evidence required to persuade a manager to change an aspect of practice might be totally different in nature from that required to deepen the academic communitys understanding of such practice.

Collaboration in Pair Programming: Driving and Switching

This paper reports on an empirical study about the mechanisms of the collaboration of drivers and navigators in Pair Programming (PP) sessions. Based on video recordings of professional software developers, we analysed the mechanisms of role switches and how developers split the task of driving. We found that developers do not evenly contribute to the task of driving and that they spend on average a third of the session without any computer interaction focusing mainly on communication. In addition, our results show that most pairs switch roles frequently and that the frequency and fluidity of switches indicate a high level of engagement on the part of both developers.

Organisational Learning and Software Process Improvement: A Case Study

This paper describes a longitudinal study of an organisation over a period of eighteen months as it initiated and then implemented a manual of software best practice. The organisation consists of end-users, in the sense that, although developing software is an integral part of their job, they are not professional software developers. Although the organisation itself was unaware of current trends in Software Process Improvement (SPI) or theories of organisational learning, our case study affords us insights into some practical deficiencies of the accepted techno-centric model of a SPI programme. We argue that such a model imposes unnatural work practices on an organisation and fails to take account of how process improvements might occur spontaneously within a community of practice.

Some Challenges Facing Scientific Software Developers: The Case of Molecular Biology

It is apparent that the challenges facing scientific software developers are quite different from those facing their commercial counterparts. Among these differences are the challenges posed by the complex and uncertain nature of the science. There is also the fact that many scientists have experience of developing their own software, albeit in a very restricted setting, leading them to have unrealistic expectations about software development in a different setting. In this paper, we explore the challenges facing scientific software developers focusing especially on molecular biology. We claim that the nature and practice of molecular biology is quite different from that of the physical sciences and pose different problems to software developers. We do not claim that this paper is the last word on the topic but hope that it serves as the inspiration for further debate.