Inforbiomatica

Last month I attended the BRIITE meeting for the first time. As its website says, the meeting’s mission is to:

• Establish personal contacts, bringing together those responsible for research computing activities at biomedical research institutions
• Identify and document common problems and interests
• Seek opportunities for partnership / consortium activities
• Identify common issues that should be brought to attention of home institutions, government and other funding agencies

One of the things I really liked about BRIITE was its focus on stimulating offline discussions. I went to the meeting hoping to find out if there were others in the biomedical informatics community who cared about software development issues. The focus of the meeting was “IT Support for Multi-Institution Collaborative Research”. We heard talks on federated identity management, Globus, GridShib, BIRN, and, slightly off-topic but still pretty neat, the Research Channel. So, the meeting was mostly about distributed security, and many attending were not primarily software development people.

Due to the focus on offline discussions, attendees are encouraged to suggest topics of interest, and then others sign up to discuss these topics as a group (a conference practice I’ve heard called a “Birds of a Feather” session). I proposed software development practices as a topic, and and a small group of us got together for a lively two-hour discussion. I will summarize what we talked about here.

People were interested in the topic for a variety of reasons. One person wanted to know how to introduce better development practices to his group. Another wanted input on how to manage many small projects at once (a common problem in biomedical informatics). Another was plagued with the problem of funding shared informatics resources at a biomedical research institution (people clearly need these resources, but no one wants to or can pay for them). Another wanted to learn more about agile software methods. Finally, I wanted to talk about how better to promote awareness and dicussion of software practices in the biomedical informatics community.

In the interest of brevity I’ll just list bullet points rather than go on and on about each item.

Funding IT

While not strictly a software development practice topic, anyone who wants to assemble a decent-sized software team at a biomedical research institution runs up against the problem of funding it. Most of the helpful tips here came from Charles Donnelly of the Jackson Laboratory.

• If these resources don’t exist, who provides seed funding to get them started? Investigators typically cannot fund these things from their research grants. Institutional funding and commitment is necessary. Where it exists, people have seen some success in developing shared informatics resources (e.g. the Jackson Laboratory).
• Funding improves if core informatics staff reviews research grants to help make them more reaslitic about informatics needs and funding. Encouraging awareness among scientific investigators and administrators is key.
• Once you have institutional funding, keep track of the time you spend on various grants. Calculate the percentage of your total work this amounts to, and tell the PIs on those grants. This will help them understand how much their informatics costs, even if they aren’t paying for it yet.
• Generally, PIs that have done some computing in the past are more forward-looking, so these are good people to start with (no-brainer).
• Funding informatics from research grants is difficult, because all budgeting is done ahead of time. Often, however, the informatics needs change over the course of the scientific project. How do you come up with specifics like $ and number of FTEs before a project begins? (The answer, it seems to me, is you do what scientists do. You make your best guess, and then you adjust what you produce based on what you have the money to produce once you learn what is possible during the course of the project.)

Project Management

Mix of suggestions and problems here . . .

• One way to scale your capabilities effectively is to develop shared resources used by several groups. Supporting shared resources can be a challenge, however, because PIs may want results formatted their own way, not in a common format.
• Before embarking on a project, draw up a project charter. This document establishes the level of involvement of key people (on both the informatics and science side) and the high-level outline of the work planned. The process of preparing this document will let you know if science people are invested enough in the project, or if there are reasons to worry. One cannot underestimate the importance of buy-in and personal investment in the success of an informatics endeavor by the science leaders on the project.
• Promote awareness of software development: Jax has a software lifecycle process approved by the institution and posted up everywhere.

Requirements/Communication

• Some used a detailed requirements gathering process (at Jax they draw up 150 page documents) to firm up what would be developed.
• Others used agile approaches, which are interactive with the scientists throughout the life of the project and make it a specific point to allow the requirements to evolve along with the scientists’ understanding of their needs.
• All agreed that requirements gathering in biomedical software has to be an ongoing, interactive endeavor - biologists sometimes want to wait until features are in production before they give feedback, they want to see something working and tinker with it.
• Underestimated opportunity for software people: helping biologists with their ad-hoc solutions (Access, Excel, FileMaker Pro) — biologists will always use Excel, so is there some way we can help them use Excel better? Can we leverage their familiarity with these technologies? A software development background teaches you to look askance on “low-tech” solutions like these, but in this domain there is something to be said for them.
• Starting with the front end (UI) and working back helps user interaction — you can show a prototype of an interface and get better feedback earlier.
• Best ideas don’t always come from biologists: we are doing our job best when we are helping scientists understand what is possible with software, and helping them focus on their goals and how software could help achieve them.

Looking Forward

We talked about possible content for a meeting or conference on biomedical and bioinformatics software development. People showed interest in the following.

• Documenting typical staffing models — help us all understand our options for organizing our work and getting it funded
• Questionnaire — find out what people are doing, try to get a picture of the current state of affairs
• Present experience reports: What working examples are out there?
• People preferred a workshop more than a conference, a hands-on experience. Plenty of short talks that don’t give answers, but raise questions - followed by open discussions.
• People would like to see defined milestones for the meeting.
• Tutorials on some subjects (e.g. project management, quality assurance and testing, good development practices) would be welcome
• Q&A sessions - what have you done that can benefit others, what are you doing?