Reusable Code

One of the things that I like about working in bioinformatics is that a lot of the software I write is situational - that is to say it's suited for one particular purpose. It gets written to do a job (typically some sort of analysis or data collation) and then discarded. Sure, there are a couple of major scripts or little applications that I've written that I use fairly frequently but most of my coding time is spent on throwaway scripts. It's the same for many of my colleagues.

In Computer Science classes we were always taught that this is not a good thing (that was in the mid-nineties - nowadays you'd hope that other methodologies get a look in too).

Personally, I think throwaway code is great - I dislike documenting code in detail, I selectively ignore object orientated design principles wherever possible and UML gives me the heeby jeebies. Just because you don't put in the extra effort to make sure that an outsider can come in and reuse all of your code doesn't mean that your program doesn't work just as well, after all - in fact, you have more time to find and fix bugs.

So we've got a Masters student (with a life sciences background) working on a project with us over the summer. The MSc in bioinformatics here is taught by the Computer Science department and his head has been filled with crazy J2EE-talk. He's doing everything by the book; drawing class diagrams, writing test harnesses - he even set up his own little local CVS repository. I should point out that I think this is a good thing. I mean, he's being graded by CS professors, or at least the coding part of his project is. If I were him I'd stick to what had been recommended to me in the lectures, too. It doesn't really bear any relation to the kind of code he'll be writing once he's actually out in the field, though. I just hope he doesn't end up believing that the only good code is reusable code.

Don't get me wrong - there's certainly a time and place for sticking to your object orientated, reusable code module guns. Bioperl is a good example of that. If you've spent some time implementing a tricksy algorithm it's worth setting things up so that you can share it with other people. If you're going to be distributing a script or program make sure that it's high quality, readable code.

To be brutally honest, though, does "everyday" code really ever get reused? What's the ratio of extra effort expended to work saved later on?

For much of bioinformatics I think that disposable software is perfectly acceptable. Partly the reason for this is that the focus isn't usually on producing fully-fledged application software for use by others but on processing data (or providing tools to process data) in the short term. What's important isn't the knowledge encapsulated in the code but in the knowledge created and then published as a paper. It's horses for courses, I guess; we should be able to accept that no single software methodology or mindset necessarily suits all situations.

Or maybe I'm just lazy.

(footnote: for more on this, check out the comments and posts at Propeller Twist and Inforbiomatica)