LOGIN | REGISTER NOW | SUBSCRIBE
 
Print

How to get (almost) everything you ever wanted in one (not very) easy step


By Richard Kennard
Email
September 26, 2012 —  (Page 4 of 4)

Grounded Theory: If you're going to be developing your thesis in close collaboration with industry developers, that collaboration needs to be framed in a research context. This can take the form of interviews, case studies, adoption studies, or other academically recognized approaches.

A useful methodology here is Grounded Theory. It's well suited to interviewing because it helps you gather observations without biasing your interviewees. Grounded Theory proceeds by first gathering the data, then codifying the data into categories and themes, and finally constructing hypotheses. It stresses that outcomes should be explicitly emergent, rather than simply verification of existing hypotheses.

You compose lists of directed but unbiased, open-ended questions that give people room to talk openly, while at the same time guiding them into the gap defined in your literature review. You then document, compare and categorize what emerges. Ideally the resultant categories will include your own understanding of the problem, but should also expose perspectives you hadn't considered.

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.

Unfortunately, in practice, academia and industry tend to fork shortly after graduation, pursuing tangential goals with limited communication between them. This is a huge shame. There is significant value in maintaining close relations between research and industry: Commercial developers can benefit from strengthening their theoretical foundations, and researchers can draw lessons from successful applications of research methodologies to industrial problems. Ultimately, this combination works to the benefit of all.

I offer my own thesis as a concrete example. The examiners summarized it as "a very satisfying, inspiring, carefully laid out, meticulously planned and executed thesis." So something like this should stand you in good stead.

Richard Kennard is an independent consultant with more than 15 years of industry experience. He is an active member of the open-source community, the founder of Metawidget, and a speaker at conferences, including JavaOne and Red Hat Summit. He holds a Ph.D. in Software Engineering from the University of Technology, Sydney.


Related Search Term(s): open source, Ph.D.

Pages 1 2 3 4 


Share this link: http://sdt.bz/36952
 
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter


close
NEXT ARTICLE
SD Times Blog: Microsoft Open Tech turns one
Subsidiary advances Microsoft's cooperative stance toward open source Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
JUNE 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?


 
 
 
 

Events calendar tab
Mobile Commerce World
6/24/2013 to 6/26/2013
San Francisco
UBM TechWeb
USENIX Federated Conference
6/24/2013 to 6/28/2013
San Jose, Calif.
USENIX
Microsoft Build
6/26/2013 to 6/28/2013
San Francisco
Microsoft
Conf. on Big Data Security
7/17/2013 to 7/18/2013
Boston
MIS Training Institute
ACM SIGGRAPH
7/21/2013 to 7/25/2013
Anaheim, Calif.
ACM SIGGRAPH