This paper presents a taxonomy of data collection techniques for conducting field studies of people-oriented activities in software engineering. As a true taxonomy, the techniques are organized and categorized. Techniques each have a descriptive paragraph on the method, a list of advantages, a list of disadvantages, and examples that are used by the authors or that appear in literature citations. To apply the methods, one must collect data, code it, and analyze it.

The paper’s title may be a bit misleading; “Studying software engineers” really studies the activities of these people. I might give it the more boring title, “A taxonomy of techniques for software development activity data collection.”

The taxonomy categorizes techniques by whether they are done inquisitively (asking the people questions) or observationally (watching them work or examining artifacts and logs of their work); by their order (fi!rst order is direct involvement of the subjects, second order is indirect involvement, and third order only studies work artifacts); by the goals likely to be achieved by the technique; by the volume of data; and by other uses of the technique in the course of software engineering.

Each technique has its method described and analyzed, from people-centric activities, like brainstorming and focus groups, used for requirements gathering and project planning, to code analysis, used for metrics and reverse engineering. The type of data to be collected varies greatly, from video, audio, and note taking in focus groups, to the mining and coding of data in software environment tool logs or the parsing and analysis of program code.

It was easy to find the situations encountered in my own work: for example, “interviews” describes both face-to-face, which used to be all that I experienced, as well as telephone interviews, which I’m now encountering as more! teams are on opposite sides of the globe. I appreciate the personal touch the authors add by drawing on examples from their own work.

Of course this is only a taxonomy, not the how-to book for the person gathering the data to conduct a task. When I’m wearing the hat of a software methodologist, there may be specific processes advocated to perform certain kinds of work, and specific metrics to collect for determining the effectiveness and applicability of processes. The value of this paper is the classification and description/discussion of each of the data-gathering techniques. This is a well-written reference paper for those performing software engineering field studies and those studying software people activities.