My dissertation is the first project I’ve done involving qualitative analysis of data – specifically, the coding and analysis of 30+ student interviews. So when it came time to choose a program with which to do all that analysis, I felt somewhat at a loss. I’d had a few recommendations from fellow grads and professors, but since I’m A) a Mac user and B) on a pretty tight budget, I found none of the recommendations fit my practical limitations. On top of that, trying to understand the features and capabilities of all the available choices was pretty intimidating, since I was working on so little experience. I worked up a lot of anxiety, not just about making the choice but about what would come afterwards as well.
On the advice of my adviser, I checked out Dedoose, a web-based program that charges per month, rather than a one-time license fee. These features, combined with a reputation for strong customer support and an intuitive, well-designed interface, struck me as a good fit for me and my project – so I went for it.
Once I decided on Dedoose, getting started was kind of exciting. The program was as intuitive as promised, and it felt good to arrange all the data I’d so painstakingly collected and transcribed into the project space. I was happy to find that many of the features promised were indeed as easy to figure out as I’d hoped, and it took only one day to upload and organize all my existing data. There were a few snags – for example, the system for categorizing data files proved difficult to understand even after repeatedly consulting the support documents – but overall, it seemed like the anxiety I’d developed about working with an analysis program during my selection process were unfounded.
The first stage of coding went fine – even great – with Dedoose’s excellent customer support on full display. Just a few weeks before, at the suggestion of another grounded theory user like myself, Dedoose had added a coding widget designed to facilitate line-by-line coding and other methods where codes are generated from the data, rather than applied to it. The widget worked like magic – line by line coding was now incredibly simple, and I was able to focus on thinking about what I saw and how best to describe it. For the first month using Dedoose, I felt back-pattingly good about my choice of program.
It wasn’t until I got elbows-deep in the coding process that the drawbacks of Dedoose for my methods started to present themselves. Turns out, while Dedoose makes initial coding a piece of cake, it has very little support for turning those initial codes into more focused sets. During my initial coding phase, I generated 195 codes – a lot, yes, but not out of proportion with the 30+ interviews I conducted. To progress to focused coding, I wanted to slot these initial codes into four “trees,” then look at which interviews and terms showed up most across the codes in those trees. But Dedoose’s interface is extremely unfriendly to this kind of sorting. The only way to place codes into trees is through drag-and-drop using this list interface. Since the interface displays only 1/5 of my codes at a time, dragging and dropping is a very slow, incredibly tedious process. So tedious, in fact, that despite starting it more than a month ago I’ve yet to finish; I keep finding as many ways as possible to work on the project without having finished the coding process.
This wasn’t something I had even thought to look into when I was selecting a program. Since grounded theory is a relatively common choice for qualitative data projects, it hadn’t occurred to me that support for its sprawling and relatively disorganized initial coding stage might be something I needed to look for specifically. It made me feel somewhat naive – but also a little wiser. Next time I choose a program for data analysis, or give advice to someone on doing so (like now!), I know to emphasize a close look at tools for coding. I knew going into my selection that coding tools were the major use I’d be putting to use, but I was too impatient to get going and too new to the process to know exactly what to look for – or, looked at another way, how to adapt my methods to the tools I’d chosen.
The shape of a project should guide the selection of tools, it’s true. But given my hardware and financial limitations, I didn’t have a wide range of choices available to me; from a practical standpoint, Dedoose was the clear choice. So the lesson I learned here is that sometimes, the project should (at least to some degree) follow from the tools available. For now though, I’m stuck with the project I’ve got – which reminds me: I’ve got some coding to do.