Get the computation done
Programming that happens in labs is typically rushed and sloppy. The goal is to get the job done right, and, almost as important, done ASAP. The goal is not to generate ultra-readable, conforming code that is full-featured and ready for distribution. This is similar to the “Worse is Better” philosophy of software development (which I’ve also seen called the “Carnegie Mellon” style, to contrast it with the “MIT” style that emphasizes completeness).
It sometimes takes discipline to stay focused and avoid the temptation to add in more features, improve the design, and make more bulletproof, elegant code. Particularly when working on very difficult biology experiments, when the control and reproducibility of programming can be a tremendous comfort and wonderful escape.
Here’s a recent, interesting discussion on the topic entitled “Do it right or do it ASAP?”.
The first priority is always accuracy. The code has to give the right answer. But as long as that’s taken care of, getting to version 1 as fast as possible is typically what I emphasize. Note that this isn’t the same as “Fail fast”, which I think encourages sloppiness. Rather it’s a prioritization of completion of a computation, ahead of the development of a mature piece of software.
What principles do you stick to when coding?
Of course, rigs have to be robust. Experimental equipment needs to be bulletproof, and it’s worth delaying version 1.0 if the alternative is a shoddy, unreliable solution that might be tempting to leave in place.
I have generally worked with biologists who knew very little about programming or interfacing a program with hardware. As a first pass, I let their immediate needs determine the stopping point. I attempt to have the program do what they want, with minimal “extras”, yet written in such a way that non computer savvy individuals can use it without too many instructions. I find that version one is usually good enough for 75% of the experimental needs. Undoubtedly, the users come back to me at a later time saying “This is great, but do you think you can add this, or have it do that?”. This leads to versions 2-10 usually. In the end the program is highly customized for the specific end user. I have had the luxury of doing this, and NOT having to make something so generic everyone can use it: a much more difficult task I am sure.
While getting things finished is important, most code (at least that I work on) is reused and built upon several times in the future. I find people trying to get stuff working as fast as possible save time on the first iteration, but get bitten in the butt on all the following iterations. And since most code will undergo more than one more iteration, it’s often a time saver to invest – some – but not too much – time in making it nice.
Here’s how I (try to) achieve that balance:
Keep the structure and architecture of the code shiny.
Kludge out the details till it works. If the details are pretty – great!, but they don’t have to be.
Details can be improved later, and optmized for speed (but profile and only bother speeding up slow/oft used parts). But structure is much harder to improve later, especially in science, where once you settle on a structure for your data and analysis it’s like pulling teeth to change it (since that usually requires re-processing old data).
[…] We’ve been over this before. Get the Computation Done. […]