Authors:
Table of links
2 Is an ethnographic study the right choice?
- The context of your research
- The kind of research questions you want to answer
- What ethnographic studies require from the researcher
3 Planning an ethnographic study
- Finding a site for field work
- Participant or non-participant observation
- Duration of field work
- Space and Location
- Theoretical underpinning
4 Implementing your ethnographic study
- Gaining access and starting up
- Handling your preconceptions
- During the study
- Going Native
- Leaving the field
- Reflective and inductive analysis
- Writing Ethnography for Software Engineering Audiences - Reporting the Results
6 Ethnography and Research Ethics
7 Final comments, Further reading and References
Abstract
Ethnography has become one of the established methods for empirical research on software engineering. Although there is a wide variety of introductory books available, there has been no material targeting software engineering students particularly, until now. In this chapter we provide an introduction to teaching and learning ethnography for faculty teaching ethnography to software engineering graduate students and for the students themselves of such courses. The contents of the chapter focuses on what we think is the core basic knowledge for newbies to ethnography as a research method. We complement the text with proposals for exercises, tips for teaching, and pitfalls that we and our students have experienced. The chapter is designed to support part of a course on empirical software engineering and provides pointers and literature for further reading.
1 Introduction
Ethnographic studies are an important element of the toolbox for empirical software engineering as they can provide unique insights into software development practice [51]. Ethnography was originally developed as a method to understand foreign cultures by becoming embedded in them and documenting the learning and sense
making that was experienced during the process [26]. Modern ethnography has been developed in an attempt to understand a foreign culture from a members’ perspective. With a growing interest in the understanding of subcultures close to the ethnographer, ethnographic research was used to learn more about a wide range of contexts including truck drivers [1], midwives [32], London underground workers [27] and organisational life [58, 64]. In the context of Human-Computer Interaction and Computer Supported Cooperative Work, ethnographic research was used to understand how the members of an organisation made use of technology. Examples for this kind of research include several studies of air traffic controllers in the context of a redesign of the system supporting their perception and control of air traffic [4], of copy machine repair personnel by Julian Orr [40], and of attorneys and paralegals to prepare the design of software supporting their document management [5]. For more than 25 years, ethnography has also been used in the context of software engineering research in order to study cooperative aspects of software engineering. Examples are a study on configuration management [28], a study on the use of social software in distributed software development [23, 24], and an ethnographic study of a small software house to investigate testing practices [39]. As in the original context, the benefit of ethnographic studies of software engineering is the understanding of how and why software teams do what they do to develop software. Ethnography allows understanding and describing collaboration in software engineering from the software engineers’ perspective. Ethnographic studies require the researcher to join a development team with the intent to understand the why and how of the team’s everyday practices.
• It’s important for students to know the origins of ethnography but introduce the approach through a mixture of examples from software engineering and other disciplines so that the relevance to software engineering comes through
• If you don’t have (much) experience of ethnography yourself then identify colleagues with experience to engage in your classes
• It’s hard to see another person’s point of view, offer your students guidance on emotional intelligence, and how to see different perspectives
• Present examples of existing ethnographies in software engineering for the students to facilitate their writing
• Take an iterative approach to topics, e.g. provide some background, set an exercise, discuss the exercise and ask students to do the exercise again
• Embrace the use of ethnography with other techniques, e.g. interviews, as these are often required in the field
• Because activity in the field is fluid, ethical dimensions of the study need careful attention
When we use the term ‘practices’ in this chapter, we talk about the established way a software team goes about developing and evolving software. Social practices, like cooperative software engineering, are based on an understanding of relevant objects, representations and tasks, on implicit and explicit rules, and on a common goal (for further readings see Section 7). Understanding software practices using an ethnographic approach aims to understand how and why the software development practices make sense from a members’ point of view, putting aside ideas on how to improve the observed practices for the time being. This can be hard for a software engineering researcher. As engineers and software engineering researchers we are trained to design and create things and to improve the methods used to this end. We tend to focus on problems and shortcomings, rather than aiming to understand how a complex activity such as software development actually takes place, or what enables a team to produce software at all. Ethnographic research invites us to temporarily put aside or ‘bracket’ [22] our assumptions of how software development should take place, and try to understand how developers make things work no matter what.
In return, the results of ethnographic research help us understand the rationale behind even seemingly disadvantageous behaviour, which in turn provides us with important information when designing tools and methods. An example can be found in [61, 62]. The article presents an interview study triangulating an ethnographic study of software architecture practices for a software product. The researchers were surprised at the lack of any software architecture documentation and the unwillingness of the team to produce and maintain such documentation. A triangulating interview study revealed that this reluctance towards software architecture was shared by architects and tech leads of other products. The only exception, an open source project, also provided us with a rationale for this attitude: the existence of architecture documentation can prohibit discussion between the architects and the developers with the effect that the architects might not know how the developers change the architecture or where the architecture creates problems for the development and might need to be revised. This, in turn, means that tools for designing and communicating software architecture should be designed to support architect-developer discussions and not replace them. Had we not taken the reservations of the developers and architects seriously, we would not have understood that there was a ‘good reason for bad architecture documentation.
Ethnographic studies can also lay the groundwork for practitioner support tools that are accepted by the community because they are based on an understanding of practitioners’ point of view. An example of this is the motivating jenny project which ran a multi-site ethnographic study to understand developers’ security behaviour. This project resulted in a number of insights including a model of security behaviour [35] that underpins a set of four practitioner packs designed to improve the security culture in a team or organisation (downloadable from motivatingjenny.org). These have been downloaded thousands of times and have been used in education and in industrial settings
Our previous, more theoretical and programmatic article in Transactions on Software Engineering [51] provides examples from empirical software engineer- ing where ethnography has been used. This chapter complements that article with support on how to implement and teach ethnographic research in a Software Engineering context. The goal of this chapter is twofold. On the one hand, we introduce ethnography as a research method for software engineering with a hands-on approach. We aim to provide concrete how-to support for researchers starting to use ethnography. Our intended reader in connection to this goal is a researcher, e.g. a PhD student, who wants to explore ethnography as a possible research method. On the other hand, we provide guidance for teachers of a postgraduate course on empirical research in software engineering. The chapter comprises what we see as the minimum contents of a module on ethnography as an empirical method for software engineering.
In our tutorials, people have often asked us what is the difference between ethnography and other qualitative methods, such as contextual inquiry and grounded theory. And why not just do interviews? A simple response to these questions might include that contextual inquiry is based on an apprenticeship model, grounded theory seeks concepts in the domain that can be developed into a theory, and in interviews participants’ accounts will necessarily be partial and rationalised. Ethnographic research, on the other hand, focuses on a holistic view of the practice being studied, has research questions that evolve over the course of the study, and aims to capture activity as it happens together with practitioners’ rationale. But there is more to it than this. This chapter will provide a deeper answer to these questions. The remainder of the chapter is structured as follows: Section 2 discusses whether ethnography is the right choice from three perspectives: the role of ethnographic studies in relation to your specific research context; the type of research question it can address; and what is required of the researcher. Section 3 discusses the planning of an ethnographic study. Section 4 covers important topics such as field work and addresses issues ranging from the role the researchers take on in relation to the team, to how to design and keep a field diary. Section 5 introduces the analysis of ethnographic data and section 6 covers research ethics for ethnography. Section 7 concludes the chapter and provides suggestions for further reading.
This paper is