Print

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



Email
September 26, 2012 —  (Page 3 of 4)

Action Research: There are several accepted, academically rigorous methodologies that can frame an open-source project as a Ph.D. thesis. The methodology I chose was called Action Research. The idea is to break your overall research into smaller cycles of building something, reflecting on what you've built, and then building some more. If you're thinking this sounds a lot like the industry practice of Iterative Development, you'd be right. In fact the phases of a typical Action Research cycle fit neatly into the stages of Iterative Development, providing an elegant way to marry industrial practice with research methodology.

The main difference is that the “reflecting on what you've built” phase needs to be much longer and more rigorous for Action Research than you'd typically undertake for Iterative Development. But that turns out to be a great thing for industrial practice.

One of the most important factors in software development is scope: deciding what to include and what to leave out. Scope creep and feature bloat are recognized risks, impacting development costs and release schedules. Good developers carefully apply rules of thumb as Google’s Joshua Bloch explained in his presentation, “How to Design a Good API and Why It Matters”: every design decision should “minimize conceptual weight.” We should strive to “kill several birds with one stone.” But an implicit difficulty in evaluating this is knowing what the birds are.

Once out of their initial planning phases, software projects have a tendency to lurch from immediate issue to immediate issue, dealing with each new requirement as it arises. Considering requirements in isolation invariably means the burden of large-scale redesign to satisfy any one requirement will seem onerous; a smaller-scale, more imperfect but less impactful alternative will always seem the better option. Over time, many such small, imperfect design decisions inevitably degrade the quality of the software.

Reflection, on the other hand, allows you to consider many weeks’ worth of problems in a holistic light: You can see all the birds at once, and an approach that once seemed over-engineered now appears justified. Surfacing all the issues at the same time clears a path forward that otherwise would have seemed prohibitive.

Another benefit of choosing Action Research is it intrinsically defines a structure for your thesis. You can do three or four Action Research cycles over the course of your Ph.D., and arrange them as chapters. In turn, each chapter can be broken down into the “planning,” “acting,” “observing” and “reflecting” phases of each cycle. This immediately helps focus your research.

I did, however, find this structure to be a double-edged sword. A common problem a lot of Ph.D. candidates face is doing all their research—and little of their thesis writing—up front. Then after several years, they face the stressful task of trying to document all their work as a coherent narrative. Action Research can help here, because it permits you to document each cycle as a self-contained chapter as you go.

However, it can also hurt. I discovered this because, while I wrote up most of my research each year, I confess I left a few sections unfinished. Action Research makes it much more difficult to go back and complete those sections later, because so much of Action Research is concerned with reflections. Proper reflections are constrained by the context of their time. Attempting to cast one's mind back not just to the particular thoughts, but also to the overall mindset of two or three years prior, is a formidable task. It requires you to remember what you knew, what you didn't know, and what you thought you knew but have since learned differently. And you must disregard that more recent knowledge, lest you end up writing a revisionist history. It's very difficult, and I would warn against trying to document Action Research retroactively.

Action Research was a hit with my examiners. One wrote, “I was very moved by the candidate's choice of methodology... So many [candidates] in computing disciplines propose new architectural approaches and prototype their approach, but [ultimately] readers are [only] left with ideas, which might work if only someone in industry ever adopted them. [This candidate's] approach... meant that his system is proven both to academic and to industry developer communities. As an examiner, on realising how widely used the system is and then reading the adoption study results, I breathed a sigh of relief. What a delight to see good ideas actually used!”

Having broken your thesis into a series of Action Research cycles, it remains to discuss what you should do within each of these cycles. Much of this comes down to simply sound software engineering: planning, developing, testing, documenting. An important part is the holistic reflection discussed earlier. Another important part is how to gather feedback and observations from industry.


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

Pages 1 2 3 4 


Share this link: http://sdt.bz/36952
 
Most Read  Latest News  Resources

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
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?