Which Software Development Technique Is Used In Your Lab?
9
4
Entering edit mode
14.7 years ago

On this page of the software carpentry manual you can find a brief introduction to different software development techniques, including agile and sturdy ones.

Which of these development model is closer to the one you use on your lab? How do you work together with your teammates?

note: If you are interested, I can provide you with more documents to describe the different development techniques.

subjective • 4.0k views
ADD COMMENT
7
Entering edit mode
14.7 years ago

As I've always worked alone on my sources, I've heavily used the Cowboy Coding and the confessional debugging techniques :-)

ADD COMMENT
7
Entering edit mode
14.7 years ago

As the number of good programmers in natural sciences is relatively low as compared to other programming projects, I think it is good to pick a model that suites the team. In these situations, I do not think coding style matters too much (write unit tests first or last, ...).

I am involved in two large chem- and bioinformatics projects: Bioclipse and the CDK. There is a bit of overlap in developers, but still both projects use different development models. Both development teams are scattered around the internet. But what does matter very much is communication. This makes the following components important:

  • choose a version control system: I would recommend Git; it does require some training, but there is plenty of information, and we all have good education to start with.
  • choose a bug track system and make this your main development communication channel: it works independent of individual developers' time lines.
  • have mailing lists to discuss issues in more detail, ask for advice, etc
  • choose coding standards: these can be small and large, and are aimed at removing getting annoyed to much about others coding styles
  • put persons in charge and have them take responsibility over the code

The CDK even adds to this that code is reviewed before it gets into the main version. Git makes it very easy to developed in such a distributed way (not just in location, but also in time). The person in charge is the gate keeper and decides how and when code gets incorporated into the main version, and ensures everyone lives up to coding and project standards.

Wikis, blogs, waves, etc are useful for documenting things. More important is to add proper documentation to the source code.

ADD COMMENT
4
Entering edit mode
14.7 years ago
Rajarshi Guha ▴ 880

think it, code it :)

ADD COMMENT
4
Entering edit mode
14.7 years ago
Nicojo ★ 1.1k

Question 1: With my collaborators, we use agile.

Question 2: (if I've understood correctly the "how do you work together with your teammates?") Our team members have very different roles and it is mainly one person actually coding. So we don't need to share code etc. When it comes to the communication part, we rely on different tools:

And most importantly, whenever we can, face to face brainstorming with a white board.

ADD COMMENT
0
Entering edit mode

Thank you very much, this is very interesting. I will wait for other answers and eventually mark yours as the accepted one.

ADD REPLY
0
Entering edit mode

I didn't know about yammer, but I will look at it. When we tried google/wave, it was too slow for being of use. It would be complicated to use a wiki because the other members will have to learn its syntax. A few of us use git, which doesn't require a central repo like svn, and github. We use skype and emails, as well as dropbox for sharing files :-)

ADD REPLY
0
Entering edit mode

Well, Wave works well for us... most of the time. One of my collaborators had a problem recently where he couldn't update anything (unsynced). A change of browser fixed it though. The "extentions" list is growing, which is good too. Maybe you should give it another try!

ADD REPLY
0
Entering edit mode

I use Dropbox personally, but we haven't used it in our collaboration yet. Will probably come in handy soon though!

ADD REPLY
0
Entering edit mode

As for Yammer, in the end we like some aspect of it, but it's not as useful as Wave, so we'll probably slowly abandon it.

ADD REPLY
3
Entering edit mode
14.7 years ago

We have lots of individual projects, but thematically close to each other. Individual means, there is a lab leader who brings the idea, a PhD student who brings them to life, and a postdoc for troubleshooting. Plus eventually one to few undergraduates who are supposed to work with the result.[?]

We are using a portfolio of Agile-inspired techniques to keep everything neat. In my opinion, using a version control system (SVN, GIT, Bazaar) is a must. For half of the projects we have unit tests and do TDD (these tend to be more successful - an observation not a causality). For implementation, we are doing Pair Programming and code reviews frequently. Sometimes we use Trac, iterations, and Kanban.

For communication, I couldn't do anything without a whiteboard and several pin boards in the lab.

ADD COMMENT
0
Entering edit mode

nice to know somebody is using agile and pair programming for science! :-)

ADD REPLY
2
Entering edit mode
14.7 years ago
Yuri ★ 1.7k

We are using 37signals' Basecamp and Backpack to exchange data, results, ideas and other staff. It's not free, but not so expensive. As for codes, we usually have individual projects. All techniques as in Pierre's answer. :)

ADD COMMENT
2
Entering edit mode
14.7 years ago
Melanie ▴ 660

To put my answer in context: I work in industry. I've worked in both small biotechs and large pharmas. I am not the coder on the projects I work on- these days, I'm the project manager. Earlier in my career, I was the "translator" between the scientists and the programmers (that job has had many different titles, and was rarely my sole job function).

I have found various permutations of agile programming to be the most successful. The one exception to this has been when I've worked on projects in the more heavily regulated drug development (vs. drug discovery) arena. In those cases, the internal processes have often required a waterfall-like process. For awhile, I specialized a bit in fitting the agile-like development approach favored by my programmers into the waterfall process required by corporate policy.

ADD COMMENT
1
Entering edit mode

Thank you very much, this is very interesting. Sorry for the personal question.. but do you have a blog, or did you write any document describing your experience? That would be very useful to many people. I would like to ask you more details but I don't know where to do it! :-)

ADD REPLY
0
Entering edit mode

Ah, well... being in industry, it is much harder to write a blog. I've signed non-disclosure agreements, etc. I have a very out of date website I put together on biological database design, which I guess I'll add to my profile. It is: http://www.32geeks.com/biodb/

My email address is somewhere on those pages. But to spare you the hunt, it is melanie_renee_nelson@yahoo.com.

ADD REPLY
1
Entering edit mode
14.7 years ago
Mndoci ★ 1.2k

Like Melanie, I've worked in industry as a programmer, as a product manager, etc. In my experience, an iterative, "agile" (without getting dogmatic about what agile means) works way better than the waterfall models. In a research driven environment with constant change, incomplete requirements and needs, I would argue it's the only good way.

The other key point, don't go for all the features you can, since chances are you will need to re-implement parts anyway.

(Disclaimer - I don't work in science these days)

ADD COMMENT
1
Entering edit mode
14.7 years ago
Ian Simpson ▴ 960

We use an agile technique with SVN using the Eclipse development suite http://www.eclipse.org/, the SVN-Team plugin http://www.eclipse.org/subversive/ and either sourceforge or an internal SVN service.

Our team work tends to be done face to face, though we do have a personal wiki and use google apps as well.

ADD COMMENT

Login before adding your answer.

Traffic: 1803 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6