Rule 5: "Be Simple", is hiding a huge range of complexity, and I feel very underdoes this hugely complex issue.
I work on an C++ app, built with cmake with one dependency (boost). It still took me a day and a half to get it to build on Windows 8. I once spent two days trying to build a debian package before giving up.
Writing Scientific Software for distribution is a painful experience, with almost no gain for the developer unless you end up in the top 1% of 1% of programs.
I'm still going to do it, but let's not pretend it is easy, or a good idea.
Also, "Release Early, Release Often", and allowing users to identify problems in your code? I've found people, very reasonably, get very angry when they get wrong answers out of my program. We've had less than a handful of "wrong answer" bugs in releases, but that came from a huge testing undertaking.
I recall our boss having a slide with a bullet that said "biologists can't code."
We deal with all kinds of scientific software and I thought this was mean. Then I got the programs, and features included crashing GCC (by doing something illegal with OpenMP), not using a BLAS, BubbleSort in tools.c, and an object oriented nightmare that should have been io limited but ran 100x slower then io.
I had a slide on my PowerPoint where I wrote "biologists can't program."
Naive advice. It seems the author is paid primarily to work on a software package for the biology field, which I think skews his view on the applicability of his advice for other scientists, for whom software is usually just a tool rather than a goal in itself. Take for example
" If your software is too complex to obtain and operate or can only run on one platform, then few people will bother to try it out,"
Seriously? He expects people to run, let alone test, support and document their code on multiple platforms? There is no grant money in doing such mundane tasks, not to mention that maintenance of such is boring and orthogonal to the original research.
Most of his advice seems to stem from ideological views re: open source software rather than from an attempt to help scientists or science in general.
The article is more concerned with "open development" than with "scientific software". Those interested in more specifically science-oriented advice might like the following, which is referenced in the OP: http://arxiv.org/abs/1210.0530. For example, this one mentions version control and testing against data.
Nice article. I think young scientists (I'm attributing myself to one of them) should contribute more to open/closed software. It allows to gain experience and also citation count ;)
I work on an C++ app, built with cmake with one dependency (boost). It still took me a day and a half to get it to build on Windows 8. I once spent two days trying to build a debian package before giving up.
Writing Scientific Software for distribution is a painful experience, with almost no gain for the developer unless you end up in the top 1% of 1% of programs.
I'm still going to do it, but let's not pretend it is easy, or a good idea.
Also, "Release Early, Release Often", and allowing users to identify problems in your code? I've found people, very reasonably, get very angry when they get wrong answers out of my program. We've had less than a handful of "wrong answer" bugs in releases, but that came from a huge testing undertaking.