Fixing the phone

Nov 27 2012 Published by under [Education&Careers]

Last week I wrote a post about lab peeps arbitrarily changing established protocols based on the pursuit of fixing their current data ailment. Based on the comments and links, this is a common issue across several disciplines.

So how do we fix it? Or at least, put measures in place to limit the potential damage.

I recognized this as an issue early on on in my life of PI, but it took me a while to settle on a system that seems to work well for my lab group. We have two main mechanisms to deal with two different problems.

Problem the first: Protocols. When I was a grad student protocols were handed down through the lab, first in hard copy (shut up) and later as a doc file. The problem, of course, is that the copy you got might be different from the copy Bridgette got, depending on who bequeathed the document unto you. To solve this, my lab uses shared Google docs for our protocols. No one changes the version on the cloud without passing it by me and new people get the unsoiled version from the shared folder. We also use project specific docs to keep track of project specific changes, advances, updates, etc. We don't go so far as doing e-notebooks, but the project docs are important for keeping people working on overlapping projects on the same page.

Problem the second: Shifty code. If you think protocols are an issue, trying having a couple of people with different programming ability adjusting code. I did not anticipate quite the scale of the problem here until we had one major train wreck, then we switched to using bitbucket. Simply put, now anytime a piece of code is changed there is a record of both versions, who made a change and what was changed. For some of our more dynamic pieces of code, the trail can look a little crazy, but it's all there at a glance.

The more people in the lab, the more we have found these changes to be vital. Yes, people have to stay on top of the entries to the Google docs, but the amount of time and money saved is huge. I therefore make it a point of emphasis that lab members stay up to date.

One response so far

  • Confounding says:

    An additional use for something like bitbucket or github is to have each project create a "branch" of your main codebase for each project. That way, not only can you look back on the changes, but you can have spun-off code for a particular project not leaking its way back into the working master code base.

Leave a Reply