Software engineering is still something that gets too little attention from the technical computing community, much to the detriment of the scientists and engineers writing the applications. Greg Wilson has been on a mission to remedy that, mainly through his efforts at Software Carpentry, where he is the project lead. HPCwire asked Wilson about the progress he’s seen over the last several years and what remains to be done.

HPCwire: We last spoke five years ago about Software Carpentry — your work to improve the software development skills of scientists and engineers. Have you been able to see any progress along this front?

Greg Wilson: Yes, on a small scale, but no, not in general. A lot of students and professionals have used the Software Carpentry materials — we get several hundred hits a day, mostly via Google searches — and based on their feedback, they do find them useful. Elsewhere, we have seen a growing number of conscientious scientists worrying about the problems of sharing and reproducibility, and other courses like Software Carpentry springing up, primarily in bioinformatics and astronomy.

Overall, though, I have to say that most scientists and engineers don’t use computers any more proficiently today than they did twenty years ago, never mind five. For example, I would bet that the percentage of grad students in science and engineering departments using version control to keep track of what they did when, and to share their work with colleagues, hasn’t shifted in that time.

HPCwire: What hasn’t improved?

Wilson: Fundamentally, what hasn’t improved is people’s ability to do math. Suppose that picking up some basic computational skills—version control, testing, Make, the shell, using a debugger, and so on—takes five full-time weeks. Whether that’s one five-week marathon, or the time is spread out over several months, it still costs roughly 10 percent of the scientist’s annual salary, if you’re thinking like an administrator, or 10 percent of their annual published output, if you’re thinking like a grad student’s supervisor.

If we assume our scientist only keeps doing research for another 10 years (which I hope is pessimistic), and a depreciation rate of 20 percent (which I also hope is pessimistic), then this only has to improve the scientist’s productivity by 2.4 percent in order to pay for itself. That works out to just under an hour per week during those ten years; anything above that is money or time in the bank. Looking at the results of the survey we did in 2008, even scientists who _aren’t_ primarily computationalists are spending a lot more time than that wrestling with software.

Now suppose the feedback we get from people who’ve taken the course is right, and that these skills save them a day a week or more. Let’s assume the average scientist or engineer costs $75,000 a year. 20 percent of their time over ten years, at the same 20 percent discount rate, works out to roughly $63,000; at a more realistic discount rate of 10 percent, it’s roughly $93,000. That’s roughly a ten-fold return on $7,500 — five weeks of their time right now at the same annual salary.

So why don’t people do it? Or to put a sharper point on it, why don’t their bosses and supervisors require them to? I think there are four reasons:

(1) Time and money spent show up in the budget; time and money saved through higher productivity don’t. Of course, this is a problem for more than just computational skills training.

(2) Sure, if I knew some Perl, I could solve this problem in five minutes instead of an hour, but learning that much Perl will take two days, and the deadline for this paper is tomorrow. And then I have to prepare a mid-term for the course I’m teaching, or fill in my benefits paperwork.  Something that pays off in the long run is not useful if all our deadlines are short-term.

(3) It’s a case of the blind leading the blind. If most of the people around you don’t know how to automate tasks using Make and the shell, for example, you’re unlikely to start doing it yourself. And yes, there are lots of good tutorials on the web, but it’s hard to find the right ones if you don’t know what keywords the cognoscenti use to describe these things, and even harder to understand them.

(4) Institutionally, the people who fight for scientific computing resources are usually those doing HPC, and because of (3), they almost always fight for more hardware, rather than the skills to use that hardware effectively. Most HPC vendors aren’t any more enlightened, which is shortsighted. If more people knew how to do simple things well, more of them would try advanced things, which would lead pretty quickly to increased sales. Right now, though, it’s easier to get a million dollars for a new cluster than a hundred thousand to train people how to use computers effectively.

HPCwire: Are there software development skills or practices that turned out to be more difficult to impart to non-computer science types than you first thought?

Wilson: Most of the difficulty has actually been our misconceptions of what scientists and engineers want, rather than difficulties on their side. Scientists and engineers _do_ tend to be fairly smart people. As a computer scientist, I always want to teach fundamental principles of computing that can be widely applied. As per point (2) above, what students can actually invest time in is solutions to the specific problems they face today. They’re happy to have the general principles explained after the fact, if ever, and even happier to infer those general principles themselves from lots of useful worked examples.

It’s sometimes possible to find a happy medium, and I think our lectures on regular expressions and SQL do so. But in other areas, where the payoff takes longer, it’s really hard to find a path where every step is immediately rewarding. For example, object-oriented programming doesn’t solve any problem that people writing hundred-line programs realize they have.

This is all complicated by the fact that for a lot of people in engineering, neuroscience, and other fields, computing means computing in a specific platform like R, SPSS, SAS, or MATLAB — and even then, “MATLAB” might actually mean a large domain-specific package on top of MATLAB itself. Most of our course materials are in Python, and while it’s an easy language to learn, someone who whose colleagues work exclusively in R will quite rightly think that learning a new language is a high price to pay for some insights whose value isn’t immediately apparent.

Reaching those people would require an retooling for every single language, which we simply don’t have the resources to do.  However, these people can and do benefit from generic material on version control, the shell, and databases, so that’s where more of our effort is currently going.

HPCwire: HPC practitioners seem to be of two minds about optimizing software workflow. Some believe the emphasis needs to be on minimizing development time, while others believe maximizing runtime performance is paramount. Often these two approaches are at odds with one another. Where do you stand on this dynamic?

Wilson: It’s a false dichotomy, and a dangerous one to boot. Given the complexity of modern architectures, the only way to make something fast is to get it working, build some tests so that you can tell when subsequent changes break things, and then start tweaking it based on performance profiling. Maximizing runtime performance therefore doesn’t compete with minimizing development time; it _requires_ it, particularly if you’re then going to have to move it to a slightly different chip set, or maybe, a few years down the road, port it to a very different architecture.

HPCwire: You recently performed a study on how scientists develop and use software? What were the major findings?

Wilson: Yes, in the fall of 2008 we did an online survey of how scientists and engineers use computers, where they learned what they know, and so on.  1,972 people responded, and we published the results in 2009. The major finding, in my opinion, was to confirm that almost everyone in science and engineering is primarily self-taught when it comes to computing, and that they’re spending a lot of time banging their heads against software problems.

HPCwire: Based on the study results, what do you think needs to be done now to help scientists adopt better software practices?

Wilson: The easy answer is, “Put more computing lab courses in undergraduate programs,” but that’s not realistic. As a physicist once said to me, “What should we take out to make room — thermodynamics or quantum mechanics?” Another solution would be to require people to pass something like a driving test before letting them use big iron, but that will never fly politically — as much as people working in HPC centers might want it to.

Realistically, I think there are only two possibilities. The first is for HPC vendors to start emphasizing these skills as a prerequisite for getting your money’s worth out of that shiny new cluster you just bought. The second is for journal editors to start requiring some evidence of competence when people submit work with a large computational component. I don’t think full reproducibility is a realistic goal, but [something like] “All of our code is under version control, it can be built with a single command, or with two commands, if there’s a separate configuration step, and we have a test suite that exercises at least _some_ of its functionality,” would be an excellent start.