Bioinformatics in the Lab: Putting a Yearly Plan Together

"Plans are worthless, but planning is everything" Dwight D. Eisenhower

Making yearly software development plans for a wet lab is at best a frightening moment, commonly a nightmare and very often totally ignored.
From the makers perspective, buried in the trenches, already overwhelmed by an avalanche of reactive tasks, making plans for he year to come can be seen as a boring process when not  a total waste of time. From the upper management one, yearly plans are a corner stone, a transmission belt between strategy and tactical realization. Middle managers have therefore to organize the planing process... before making it happen.
The situation we'll consider in this post is a common one in a research environment, when bioinformatics plans have to be drafted to support a wet lab effort. The process described here is designed for a medium size entity, eventually part of a larger organization. It consists for example in a lab with thirty-like scientists and technicians ran by five group leaders. This lab is supported by a group of five computer folks, bioinformaticians or computational biologists. Let's also consider that the whole group already works together on the longer term, therefore killing the business analysis barrier. In other words, people are used to talk to each other and they know what they are talking about.
Drafting plans cannot be a top down process, it must take into account multiple perspectives: the strategic ones, relayed by lab managers and the practical ones, voiced by the makers, the bioinformaticians. Moreover, everyone must be listened to (a hardly achievable process in large scale passionate meetings.) Adoption shall be general and funnier tasks must be mixed with less exciting ones.
We propose a four steps process:

• gathers the tasks,
• estimate the effort,
• individually prioritize,
• make the One Plan.

The overall planning is facilitated by a single person, navigating across the different contributors. This orchestrator shall have a fair understanding of the scientific domain but should come from the computational side, with a better sense of the technical complexity. Two global meetings are needed: a short one up front to explain the process and a longer one for the last step.

Looking for a path, in Polar Bear area - Spitzbergen 2001

Problem solving & low scale decision process

In this post, we’ll try to address the decision process that happens at low scale, more precisely within a team of 2-8 people building software (see http://alexandre-masselot.blogspot.com/2011/08/creating-scientific-bioinformatics.html for the role of such a team). By low-scale, we mean that we will not talk about high level orientation choices (even though there is much in commons), which are out of the scope today.
Once a goal as been stated beforehand (upper management, marketing, scientific, sprint start meeting or whatever), we must decide on how this goal should be reached and it is exactly this step that we’ll talk about here.
Such decision taking is of course a daily process in software development that can involve the full team, a subset for a dedicated aspect, a mix of developers and customers or even only two persons in pair programming. It can cover brain storming, architectural aspects, risk planning, strategy, task scheduling, technology choice, minimal viable product target (http://en.wikipedia.org/wiki/Minimum_viable_product), software design etc. This process can take a few minutes, one hour or even full days (off-site brainstorming).

20% of blue sky

Motivating software developers in a scientific research environment... 

...and getting benefit from it

Having managed individuals and teams of bioinformaticians (i.e. developers creating software tools for life scientists) and observed practices around me in other fields (and literature), I try to address the question of how to create an environment where people feel good, work at their best, produce good software and get fun from it.

There is much more to say (and so many books to read) about how to build such an environment but I will present here some views on one particular aspect, the 20% “free” time, that can easily be implemented, and the kind of benefit the company can get.

After exploring the concept in the industry, we’ll try to make a proposal on how can (and “why should”) a research center (academic or private) implement the 20% rule for the tool maker developers.

Creating scientific (bioinformatics) software: going Agile?

This post is the summary of a few personal thoughts about scientific research software development process. This is the results of personal experiences as phD in physics computational modeling, bioinformatician up to head of software development (CTO) in a medium size biotech software company (www.genebio.com), academic research/service group leader and programming course lecturer. These thoughts are based on a lot of personal failures, some success stories, even more observations of other projects and of course literature (see references)...

Verbier to Zinal in speed flying, 2009