No, we don’t have a list—not yet—but we’d like to. What short, readable papers or articles do you think every scientist doing computational work should read at some point in their career (preferably early in their career)?  Paul Dubois’ 2005 article in Computing in Science and Engineering on maintaining correctness in scientific programs is a favorite of mine; so is Evan Robinson’s summary of research on the effects of overwork on productivity. (Actually, I think everyone should read Robinson’s article, not just computational scientists…) What else should be on the list? To qualify, entries must be short (up to a few pages long), well written, of broad general interest, and have something important to say that’s relevant to our target audience. Suggestions in the comments, please…

Mark Guzdial recently posted some interesting (and for us, slightly depressing) statistics about MIT Open Courseware. Long story short, it looks like that flagship effort isn’t as widely used as many of us had hoped or believed.  I can’t find equivalent stats for the Khan Academy (a scrappy “agile” alternative to MOC that has been getting a lot of attention in the geek community), but even if I could, those numbers probably wouldn’t answer my real question: who is this reaching, and what impact is it having? As Guzdial points out, asking users to self-report is subject to large sampling bias, as is googling for links back to lectures. Our sponsors want to know who’s using our stuff, and whether it’s helping them: how do we answer those questions?

We’ve just made a few changes to the layout and look and feel of the Software Carpentry site.

• The blog and new content is now accessible directly at http://software-carpentry.org/ Version 3.0 of the course material is still available at http://software-carpentry.org/3_0.
• We’ve put all of the new content under the Topics menu, and shuffled a few of the other pages around to make things easier to find.
• We’ve updated the WordPress theme to one that works better for embedded screencasts.

Let us know in the comments how you like the new configuration, and if you find any glitches.

Via a comment from Scooter Morris: the University of California San Francisco is offering a “short course” variant of Software Carpentry under the course codes BMI-280/BMI-219. Their slides are online in S5 format, and include lots of useful stuff that aren’t in the stock version.  If you know of other offerings, please send pointers!

I’m very pleased to announce that the Fall 2010 offering of this course to Ontario graduate students is now full: we’ll be sending acceptance notices to applicants tonight and tomorrow. We hope to offer it again starting in January 2011, so if you didn’t make it in this time, please check back in December.

I’m not much of a graphic artist (in both my startups, I was told after a few weeks that I was never to work on the user interface again), so I’d appreciate your help designing a flyer/noticeboard poster for Software Carpentry. This PDF is what I have so far; anything more constructive than, “My eyes! My eyes! Aargh!” would be very welcome.

I’ve been fond of invasion percolation since I first encountered it: the problem is simple to state, but its implementation brings up quite a variety of useful ideas, from testing in the face of randomness, to associative data structures, to the limits of parallelism.  It’s a good size, too: I can develop a first version in front of students in about 30 minutes, then branch off in various directions for almost as long as they’ll listen to me.

We now have three volunteers working on similar problems: phylogenetic tree reconstruction, a Galton box simulator, and an image processing widget that will find and label stars in photos of the night sky. Today’s question is, what other small apps do you think would make good examples for this course? Candidates must be related to science in some way, and must be buildable in a couple of hundred lines of not-insanely-intricate code. (And of course, we’ll award bonus marks to people who volunteer to implement their ideas too

Dr. Roscoe Bartlett (Sandia National Laboratory), Dr. Jeffrey Carver (University of Alabama), and Dr. Lorin Hochstein (University of Southern California) are conducting a survey of software development practices among computational scientists. This survey seeks to understand current software development practices and identify areas of need. The goal is to produce a report on the status of scientific software development which can serve as the basis for future work in this area. The survey should take approximately 15 minutes to complete.

The survey can be found here, and has been approved by The University of Alabama IRB board.

The first five episodes of the lecture on Make have been recorded, edited, and posted. I still need to do one on using Make to track data provenance, but as I discovered when I started to write it, there are a few other topics I need to fill in first.  I will do an episode on managing C/C++ compilation with Make first (probably after I return from teaching in Colorado next week).  As always, comments are welcome.

Yesterday, Michael Feathers tweeted that, “The hardest bit of TDD [test-driven development] for ppl in scientific computation is that they often don’t know what their intermediate results should be.” I’d go further: if the average scientist or engineer knew what the output of their program was supposed to be, they wouldn’t need to run the program. And if you don’t know what answer is right, what do you compare your tests’ output to?

Coincidentally, one of our readers sent us this a couple of days ago:

Forgive my ignorance, but I have just watched all the lectures on testing, and I’m a little fuzzy on how I can put all this knowledge to use for me.

I do CFD programming to solve fluid flow and heat transfer problems.  I write in Fortran, code that solves an entire problem start to finish (obviously a collection of subroutines and modules). Then I use Python as a “driver” to set the values of my input variables, create input files, run the compiled code, write output files and gnuplot files to create some plots. I loosely follow the logic in Hans Petter Langtangen’s book.

Most of your lectures pertained to testing functions.  I hardly ever use them—should I be?  And how can I independently test a subroutine—or should I be?  Lets say that I run the code to solve a known problem—should I use the same pass/fail criteria that you talk about in the lecture?

What about testing to find the right values for variables—i.e. grid resolution studies.  Should I automate these?

I really would like to get these concepts clear, because I don’t do ANY regression testing right now, and I know (as you point out) how dangerous that can be.

I have some answers, but before I post them, I’d be interested in hearing from other readers: what do you do? What do you expect others to have done when you’re reviewing their papers?

Note: readers interested in this subject might enjoy Rebecca Sanders and Diane Kelly’s paper, “Dealing with Risk in Scientific Software Development” (IEEE Software, 25(4), July 2008).