The programming we choose to do in our team is like the neck in the hourglass representing life science research and technology:
- There are many grains of sand above us. Those represent all the software tools developed in life science research.
- There is a large void below us. This represents the need for widely applicable tools in the life sciences.
- At the bottom there are also grains of sand. They are well settled. These represent the current technology: commercially available tools and well-serviced open source packages.
How does the sand get from the top to the bottom? Via the neck of development. It is narrow; only few academic tools make it to the bottom. The flow through the neck is powered by:
- push: a few academic groups that have the capability and capacity to make their tools available
- pull: a few companies that look far ahead and are able to see and use the potential of an academic tool
In our hourglass of life science tools, new sand is being added at the top all the time. And most of it overflows the beaker after a while. Some tools never deliver what the author thought they would do. Some are made to solve a single problem and rightfully abandoned when that is done. But many tools are published and left as orphans. Only a selection of tools that promise to be useful for a larger audience ever make it to the neck.
In practice, the neck is too narrow. There are many more valuable tools than are taken up. A team like ours can help to make the neck larger by making existing research tools applicable for wider use as a service to life scientists with a clear need (we call it professionalization). But it is sometimes hard to convince funding parties to pay for this. It is also hard to convince researchers to work on making their software better: professionalization does not generate new high-impact papers. We work on convincing the funding parties that it is better to professionalize existing successes than to reinvent them using research money. And we work on convincing the scientists that professionalization of their output will lead to higher citation scores on their existing publications.
Science wants novelty. And the current Dutch finance climate is directed towards applied science, towards innovation in society. Look at the picture, and you can see that these are hard to combine. Innovation starts where novelty ends. The only way to make the combination is to include development.
Photo by graymalkn on flickr
This is one of the syndromes we're trying to fight in BioAssist...
The project management podcast episode 189, talks about what projects can learn from social media. I recognized many points relevant to our organization!
In an organization with more than two people, most likely there is a hierarchy. Some people are managing others.
On the other hand, project leaders are not necessarily managers of the members of the project team. Project leaders can not give orders to get things done. In our organization it is even worse: project team members are employed by different universities and hospitals, and the project leaders are in our separate group. Orders will not work.
A question that comes up sometimes is: how can one manage a project and its team members without giving orders? Sometimes this comes in the form: for you things are much easier, you are the boss and can tell everyone what to do; I do not have such power over the project team. My answer to that is: how often do I order you what to do? And if I'm not ordering you what to do, how do we run a coherent organization?
The clue is: don't tell people what to do, convince them instead. Build trust (this takes a while), and then use your expertise to convince the members of the team to align.
In fact in larger organizations, managers do not use orders a whole lot. Trust (and expertise) are much more effective. And this gets stronger higher up in the organization, up to the CEO. The biggest problem with managerial power is that it wears off when you use it. Trust grows when used properly.
Don't manage by giving orders. Act like the big company CEO.
For more inspiration, listen to this Manager Tools cast.
[Image credit: Giving orders by lincolndisplayimages.com on flickr]
We did experiment quite a bit with different ways of having our group meetings. At most of our meetings some of the group members are joining us from remote locations, and we want the remote members to be full meeting participants.
For a little while we only shared the sound with the remote participants, using skype. That worked rather well, but it brought the difficulty that the remote participants could not see the same screen that we were projecting on the wall in our meeting room. If we had only one remote participant, we could transmit a lo-fi image through video skype, but this was hardly better than no screen at all.
We then started trying different web-meeting software: a free trial of gotomeeting, and the free version of dimdim (when it was still available). Gotomeeting had the problem that it is not supporting Windows, Mac and Linux equally. Dimdim had better support for different operating systems, but had much worse sound quality and the video was sometimes completely black or delayed by as much as 10 seconds. These "official" solutions did therefore not lead to better communication for us.
Our problem was solved when we realized that we could use skype for audio, and all share the same screen by using VNC. We installed a VNC server with (readonly) java client on one of our linux servers. During a meeting, the meeting facilitator is in control via a read-write VNC session while the other participants only watch. Audio connection is done via skype as before, delivering good quality audio through a special external speaker/microphone combination.
This made us very happy, without monthly subscription costs. I'd like to hear in the comments about other alternatives you have explored.
Update: David van Enckevort explains in a posting on his blog how to set up a VNC server like we did.
Our team is working with a number of task forces in bioinformatics. Each of those task forces was started to collaborate on the development of a platform for their sub-field: a set of software tools that work together to solve the problems that everyone in the field needs to solve. Developing the platform does not require any new bioinformatics developments: the purpose is to put existing tools together.
The advantage of having these platforms available is obvious:
- to a biologist the advantage consist of having all the de facto standard tools available under the press of a button.
- to a specialist bioinformatics researcher working on a new tool the advantage is that he does not have to deal with the intricacies of all the other tools, and is able to plug his new tool into the platform using well described protocols.
To get to the development of such a platform there is a bootstrapping problem. The situation is like a table with biologists sitting on one side, bioinformaticians at the other side. Above the table, a thick (volcanic?) fog. The layout of the platform is drawn in diagrams on the table: all the tools making up the common work flow, with all their relations. On the side of the bioinformaticians, the diagram shows the concrete tools. Through the fog, they can vaguely see the workflow on the other side of the table. For the biologists, the situation looks completely different: they have a clear view on the concrete workflow they need, but the tools are vague entities that are only visible through the thick fog.
Without good support from a project leader that can listen to people on both sides of the table, the bioinformaticians will try to solve the very concrete problems they encounter on their very concrete individual tools. A little optimization here, a better data storage facility there. None of this is visible for the biologists.
This is why we put project leaders from our engineering team into each of the task forces. They will direct the focus of the bioinformaticians towards more visible changes. Work on common data formats. Work on (common) user interfaces.
Getting things to work together will bootstrap the true collaborative advantages. It will blow away the fog. Suddenly the biologists will be able to see what is going on. They will be able to provide directed feedback. And the bioinformaticians will be able to see the workflow even from their side, and build upon it.
Image credit: Three views of three tables, by EJP Photo on Flickr.
A lot of very good software in academia is developed by PhD students or post-docs. Both groups have temporary contracts, and very often the software dies at the end of the contract.
One can compare academic software with a Formula 1 race car: it is very fast, beautiful, technologically advanced. But it is very difficult to drive and needs frequent service. The only way of keeping it on the road is to have the driver and the designer working closely together.
To make it possible to use the technology that is developed for the Formula 1 race car in practice, the car must be redesigned:
- It must be possible for anyone with a normal drivers license to drive it.
- It has to be possible to drive on different types of road, not only a polished race track.
- It must be possible for a regular trained service engineer to service it.
- The service interval must be raised from 200 km to 25000 km.
It is obvious that in car design, these changes are not the responsibility of the designers in the Formula 1 team. There are other designers that are specialized in normal cars.
The equivalent concepts in software design are:
- The program must be made user-friendly. It must be usable by casual users that are not also computer hackers.
- It must be robust enough to work on real data as encountered by real users.
- Running and installation must be well documented.
- It must be able to run unsupervised for many data sets and not break down after limited time e.g. through a seemingly unrelated upgrade to the operating system or a minor change to an underlying web service.
Funny enough, in many larger projects it is expected that the designers of the Formula 1 software will also do this redesign. This is a strong contrast with car design! In NBIC-II we will not make this mistake. Taking software the extra step will be one of the important tasks of our Central Engineering Team. And this team will contain specialists in industrial strength software engineering.
We will turn the Ferraris into Volkswagens. And we will be proud of them!
This week, the Management Team of NBIC has agreed to a new operation plan for the BioAssist unit. This now puts the BioAssist Engineering Team on firm ground. We will have three important tasks:
- Guarantee interoperability of biological data
- Be consultant and project leader for the academic task forces within BioAssist
- Accept academic software and make it usable by others
I am excited to get going.