The Discovery of Grounded Theory Practices for Software Engineering Research

Abstract

Software engineering (SE) research addresses not only technical issues but also human behaviour. SE is considered as an immature discipline because many technical and social issues concerning software development and management have yet to be specified. SE in general is inclined towards quantitative approaches. Nevertheless, qualitative methods are still appropriate for SE research as the methods encourage deep understanding of subject matter. Grounded Theory (GT) is regarded as one of the potential qualitative methods that is applicable to SE research. The method is able to transform less and unknown SE phenomena into cohesive theories through systematic discovery of empirical data from the ground. This paper shares some encounters of using GT in SE research based on the reflection made on several SE research projects covering various phases of software development life cycle. The encounters are then transformed into adaptations and classified as GT practices for SE research, as an effort to inspire the spirit of using GT in SE particularly among novices. The practices embrace aspects concerning formulating research questions, handling preconceptions, utilising software tools, getting access to data and presenting theory and its development process. To illustrate on how the practices were derived, a case study is presented. The proposed GT practices could act as the starting point of adopting GT in SE research. They shall be refined and improved in future to possibly become best practices when more and more experience of using GT in SE are obtained.

Relational coding: Enhancing the transparency and trustworthiness of grounded theory research

“…Finally, a number of contributions have been made to GT through its application to information systems and computing. One useful attempt to clarify coding is rooted in the work of Allan (2003) who utilises Key Point Coding. For Allan (2003) coding became too cumbersome at the micro level, leading him to focus on coding on a key-point-by-key-point basis.…”

“…One useful attempt to clarify coding is rooted in the work of Allan (2003) who utilises Key Point Coding. For Allan (2003) coding became too cumbersome at the micro level, leading him to focus on coding on a key-point-by-key-point basis. This approach begins with identifying important incidents to code and assigning them an identifier which allows the researcher as well as the reader to track the origin of the code.…”

“…Building on this first phase of identifiers and codes, codes are then compared to one another (a process which can be tabulated quite neatly using all of the identifiers) so as to locate commonalities and produce concepts, before building towards theory. Allan's (2003) use of diagrams and tables provides useful insight into coding and Key Point Coding in particular. While it demonstrates a great awareness of constant comparative analysis and the process of drawing codes and concepts into relation with one another, it appears to stop short of indicating how to render these relationships transparent.…”

“…His most powerful contribution is in demonstrating a tool which allows for replicability of process, without expecting replication of results (Bowen, 2009). In this manner, the steps of the researcher can be easily traced, as with Allan's (2003) Key Point coding technique. Going beyond a mere transcript of the research, the idea of an audit trail is rooted in the need for GT to render the analysis process transparent and trackable.…”

“…In the course of my own attempt at learning how to do GT coding, I found multiple inputs rooted in the methodology's various strands from established and emerging voices in the field alike, including: Holton (2005, 2007), Holton (2007Holton ( , 2010, Strauss (1990, 2008), Strauss and Corbin (1994), Charmaz (2008Charmaz ( , 2014Charmaz ( , 2017, Clarke (2019Clarke ( , 2003Clarke ( , 2007, Allan (2003), and Bowen (2009) among others. These various strands are characterised by varying degrees of clarity when it comes to how to code and how to demonstrate that one has done so reliably, leading many to believe that GT researchers suffer from 'methodological incompetence or fragility' (Bryant, 2002: 32;Glaser and Holton, 2005;Strauss and Corbin, 1994).…”