Coding is easily misunderstood as the ‘basic’ or ‘essential’ function of qualitative data analysis software. In this essay, I discuss how this misunderstanding connects to the technical ease of coding in software; to wide-spread anxiety concerning doing methodologically driven analysis; and to common contexts in which software use is taught.

Technical Ease

One reason for perceiving coding as a (or the) essential function in QDA software might be the sheer technical ease of coding in most programs. From a technical point of view, coding in QDA software is a process of indexing, or tagging data. You make a label, and you attach that label to data. It’s easy. It takes a few clicks.

Software numbs Anxieties

Because it's easy to do, it's satisfying to code in software. You grab a piece of text and put it into a bucket. Boom. You assign a color to the bucket, and you see a colored strip show up on the screen. Fun. You did something. You left your mark on the data. Click-click. Just like this. The physical-mechanical process provides a sense of agency. I think this sense of agency makes software a great tool for getting people excited about engaging with qualitative research. But there are two fundamental dangers connected to this feel-good aspect of coding in software.

The first danger is connected to what qualitative methods are supposed to do. They’re supposed to foster openness, reflexivity, and intersubjectivity. In order to do that, they’re designed to help you question yourself and your assumptions. The immediate satisfaction of putting something into a bucket is in stark contrast with the confusion and insecurity that qualitative methods foster by design. Qualitative awareness is questioning; qualitative methods make reading more complicated. Coding, as a mechanics, as an activity performed with a mouse on a screen carries a dangerous illusion of security where methodologically we should be insecure.

The second danger is connected to academia as an anxiety-inducing discourse. Yipes, it’s scary out there. Doing research is nerve-wracking. Writing methods sections is intimidating. Using software - using a tool that promises to make scary processes manageable, and doable - can be part of procrastination strategies (Gilbert 2002: 219), and it can numb methodological anxieties. ‘I don’t know what to do with my data - well, at least I'm coding.’ Coding in software is juicy. It's satisfying. It gives you the feeling that you're actually doing something. It’s a warm blanket when you’ve got cold feet from standing in a murky puddle of data. This makes coding such a tempting 'first' function to use, and that’s why methodologists (e.g. Suddaby 2006; Richards 2002; Johnston 2006; Tagg 2011; Lonkila 1995; Coffey/Holbrook/Atkinson 1996) repeatedly suggest that QDA software use is uncovering – or even amplifying – a “neurotic overemphasis on coding” (Suddaby 2006: 638), even a “coding fetishism” (Richards 2002: 269) in qualitative research.

Teaching Software Use: Audiences & Contexts

In 2002, Carvajal (32-35) pointed out that software workshops are often focusing on mechanical (rather than methodological) aspects of software use; a quick google search for software workshops illustrates the extent to which this still rings true. Why are coding functions often introduced first, or framed as 'basic functions' in many workshops?

As a mechanical process you do with your hand - not as an intellectual process you do with your brain - coding does not require much conceptual engagement. A coding function can be illustrated and practiced by more or less mindlessly tagging a piece of data (for example: Let’s code everything Billy said with the code “Billy”). Time is the central issue when scheduling education around software. Teaching coding functions within a short time frame is much easier than showing writing functions in software - because it’s easier to mindlessly code than it is to mindlessly write. When time is a scarce resource, it is not surprising that functions that can be quickly illustrated or executed get prioritized over those that can not.

Fragmented audiences are another factor. Let's say I do a workshop with a group of evaluators. Each one of them works on a different study; each evaluator uses different methods, has different data; each one of them may have different needs, conceptions and ideas concerning what methodically driven work in qualitative research means in their project. In a context like this, it is tempting (and much easier) to dial down the software instruction to technical instruction, and to focus on certain software features. The coding function is juicy. Lots of 'ohs' and 'ahs' in the audience. Colorful coding strips and impressive queries all around.

A note on Teaching Software and Methods: Use the Dark Side, We Can.

If software use is not integrated into methods teaching (or: if methodology is not deeply embedded in software teaching) we strip the software's mechanical steps of the very essence that it is supposed to support. As a result, it is not surprising to see an overemphasis on functions that CAN be utilized methodlessly and mindlessly in research practice - as opposed to functions that cannot be used methodlessly and mindlessly.

However, the ease of coding – and its empowering effect – can be a powerful hook for educators. Engaging in coding as simple sorting can create a bridge for learners with an objectivist or positivist disposition. If we start a work session using the software feature ‘coding’ as a sorting mechanism, we really quickly get to a point where sorting becomes hard. We reach a point where decisions need to be MADE. DISCUSSED. CREATED. MAINTAINED. CO-CONSTRUCTED. Now it’s qualitative methods time. Utilizing the software's tempting ease and empowering quick rewards can, if harnessed by the educator, lead towards an understanding and appreciation of the qualitative perspective and its concrete analytic methods.

As an educator I can use this bridge - because I can shape where this bridge leads to. The ease of the coding function relates to the implicit or explicit hope that software will make things easier and faster. A quick look at software companies' websites will illustrate that this hope does not come out of thin air. As methods educators, we can use this hope as a hook. Not as a hook for using software. But as a hook for engaging with qualitative methodology. This requires that we consciously integrate qualitative methodology training and software training.

Literature & Credits

Carvajal, Diógenes (2002). The Artisan’ s Tools . Critical Issues When Teaching and Learning CAQDAS. In: Forum Qualitative Social Research, 3(2). [April 2013].

Coffey, Amanda/Holbrook, Beverley/Atkinson, Paul (1996). Qualitative Data Analysis: Technologies and Representations. In: Sociological Research Online, 1(1), [April 2013].

Gilbert, Linda. S. (2002). Going the distance : “closeness” in qualitative data analysis software. In: International Journal of Social Research Methodology, 5(3), 215–228.

Johnston, Lynne (2006). Software and Method: Reflections on Teaching and Using QSR NVivo in Doctoral Research. In: International Journal of Social Research Methodology, 9(5), 379–391.

Lonkila, Markku (1995). Grounded theory as an emerging paradigm for computer-assisted qualitative data analysis In: Kelle, Udo (Ed.): Computer-Aided qualitative Data Analysis. Theory, Methods and Practice. Thousand Oaks: Sage, 41-51.

Richards, Lynn (2002). Qualitative computing — a methods revolution ? In: International Journal of Social Research Methodology, 5(3), 163–276.

Suddaby, Roy (2006). From the Editors: What Grounded Theory is not. In: Academy of Management Journal, 49(4), 633-642.

Tagg, Clare (2011). Reflecting on the Impact of Qualitative Software on Teaching. In: Forum Qualitative Social Research, 12(1). [April 2013].

Thumbnail image via flickr creative commons (CC BY 2.0) by Beta-J; color hues were changed, image was cropped.