Like reviewing literature, interviewing is an alien activity for most developers. You may find your interview sessions start out stilted and take some time to warm up, both for the interviewer and the interviewee. This is understandable. Users of open-source software are conditioned to sporadic levels of support. Most community message forums, blogs and defect trackers are maintained on a voluntary basis. Responses are not guaranteed and can be minimal. It is therefore surprising (and highly regarded) for an open-source team to not only respond to a user’s immediate query, but also follow up to understand their broader use case. Users generally respond well to such diligence: “[this author] is a very driven developer who really puts effort in trying to match [his or her project] with the use cases of the users.” Those users that consent to interviews provide valuable input to the evolution of the project, something they have a vested interest in.
Similarly, many researchers have a deep interest in reading conversations with industry developers. Such conversations can be hard for researchers to come by for several reasons. First, interviewing and analyzing results is a time consuming process. Second, it can be difficult for researchers to gain access to industry figures. Third, it can be expensive to allocate budget to conduct such field operations.
All these factors mean that any work produced in this area is valuable and generally well received. As one of my early reviewers put it: “The authors include results from interviews conducted on senior software development practitioners, that actually justify their thoughts… The work is exceptionally well motivated.” My examiners agreed: “In addition to the [Action Research] methodology, the candidate skilfully uses a variety of techniques and tools (interviews, forums, blogs with special attention to industry practitioner’s feedback) for collecting information later used to design further research cycles. These [are] cleverly mixed, providing meaningful research results, difficult to dispute.”
This last point, that it makes your research difficult to dispute, is a decisive weapon in your arsenal. You’ll be on much stronger ground during your Thesis Defense if you have a battery of detailed quotes from industry developers vouching for the efficacy of your research. Another way to make your research difficult to dispute is to have portions of it peer-reviewed ahead of time. This can be accomplished through conference papers and journal articles.
Release early, release often
As mentioned earlier, one of the dangers Ph.D. candidates face is producing several years of research without ever trying to document it into a coherent narrative. They then face an uphill task at the end. One excellent way to mitigate this risk is to apply the software development practice of Release Early, Release Often to your thesis itself.
You can achieve this by periodically packaging up sections of your thesis and publishing them as “findings to date.” Such findings are typically published either as 10- to 15-page conference papers or 20- to 25-page journal articles. Given your overall thesis will run to approximately 100 pages, you should be able to extract four to six such publications over the course of your Ph.D.
There are different rankings of both conferences and journals, with different levels of difficulty in being published in them, and corresponding levels of prestige if you do. You should make sure you target realistic publications; you’re unlikely to be accepted by Science or Nature! Personally, I found journal articles easier than conference papers. Although they’re required to be longer and more detailed, you’re generally given multiple chances to revise and resubmit based on reviewer feedback.
I found this cycle helpful to improve the text and have the article accepted. Conversely, conference papers are generally a one-shot affair: You write the paper, submit it, and if it doesn’t get accepted, you have no recourse. You can submit to a different conference, but then you’re met with a different panel of reviewers who may have different judging criteria.
Many software developers begin their careers by graduating from university. On graduation day, they are surrounded by their peers. Some will go on to work in academia, most into the industry. The way it’s supposed to work is that the academic community surveys the trail up ahead, cutting through the dense forest of possibilities and clearing a promising path. Industry then follows behind, laying down a proper road and bringing in the heavy equipment.