Horses for courses
(Post updated 10/27/05; I didn’t quite like the previous version.) This post is in response to a comment I received from Greg Tyrelle, which reminded me of posts I read on Flags and Lollipops and Propeller Twist several weeks back, and wanted to comment on. I think a longer post is more appropriate than a shorter reply to the comment.
When I came across Stew’s Flags and Lollipops post myself several weeks ago, I enjoyed reading it. My favorite line is the second to last one: “we should be able to accept that no single software methodology or mindset necessarily suits all situations.” I completely agree, and I’m glad to see a bioinformaticist reflect on what approach might be most appropriate to a common form of bioinformatics programming — what we might call paper programming, in which only one programmer ever sees/edits the code, and the code gets thrown away once a paper is published.
However, I don’t think it follows (as Greg implies some may believe) that such bioinformaticians can therefore blithely shun discussion of software methods (indeed Stew himself patently is not a shunner). Rather they should be aware that they have explicitly chosen one method over the other methods available to them, and they should be able to provide decent reasons for choosing so.
In addition, paper programming isn’t the only kind of bioinformatics software under development today (as Fabrice Jossinet points out in his response to the Flags and Lollipops post). A couple years ago I came across a presentation by Maury Leysens that attempted to categorize bioinformatics software projects by the method most appropriate for their management. I thought this was a great effort, and it makes the same very important point that we should not approach every bioinformatics project with the same methods and expect good results. Our work is not homogeneous.
Choice of approach, of method, determines how we go about our daily work. In a very fundamental way this choice affects both our results and our job satisfaction. For this reason I find it strange (as I’ve said before) that in our community this choice receives so little discussion.
You see mistakes being made with both too little and too much structure. On the one hand, you see bioinformaticians and biologists slogging away at their informatics with no thought given to software practices, and everyone suffering for it. On the other hand, you have bioinformaticians who insist that their ISO-9001-approved, iron-clad, high-ceremony, bend-over-backwards-quadruple-backflip methods are the only way anyone will ever produce an acceptable bioinformatics tool. These folks can miss out on the opportunities that occur when people have more room to experiment and have a bit more fun.
More important still, there are groups out there that are figuring out better ways to approach building biomedical software. Yet we don’t often hear about these improvements except by accident. As I’ve said before, I think it would be valuable to our community if we started talking about software methods more often, so we can learn both from the broader software community (where these things are discussed commonly) and from each other’s experience.
I think that this discussion is becoming increasingly important to success in biomedical informatics. The types of applications we are asked to build are becoming more heterogeneous. More and more we are being asked to produce systems that outlive the publication of a paper. Informatics projects require more attention to the selection of appropriate software development methods than they have in the past.
Enough generalities. I have been working on a post about user collaboration in biomedical software that I will finalize in the next day or two (or three . . .), so please look for that if you want to hear something more specific.
(Footnote: regarding software reuse (the subject of Stew’s original post), there was recently a nice post, “What the space shuttle taught us about reuse“, on Code Craft about it. Just doing my part to bring software people and bioinformatics people together : )