Greg Wilson, D. A. Aruliah, C. Titus Brown, Neil P. Chue Hong, Matt Davis, Richard T. Guy, Steven H. D. Haddock, Katy Huff, Ian M. Mitchell, Mark Plumbley, Ben Waugh, Ethan P. White, Paul Wilson
Abstract
Scientists spend an increasing amount of time building and using software. However, most scientists are never taught how to do this efficiently. As a result, many are unaware of tools and practices that would allow them to write more reliable and maintainable code with less effort. We describe a set of best practices for scientific software development that have solid foundations in research and experience, and that improve scientists' productivity and the reliability of their software.
Linked by 3 identifiable commenters in 3 comments across 3 threads, from Nov 2012 to Oct 2014. Found in 6 HN submissions from Oct 2012 to Nov 2014. Open submission discussions.
This sounds like a gap in the curriculum that could be filled by grad students. I'm not in CS, but I know that the bioinformatics students have organized a course that covers some basics of the unix command line tools, probably because data conversion is a big part of most…
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…
Recent version is v2 http://arxiv.org/abs/1210.0530v2 Summary: 1. Write programs for people, not computers. 2. Automate repetitive tasks. 3. Use the computer to record history. 4. Make incremental changes. 5. Use version control. 6. Don’t repeat yourself (or others). 7. Plan for…
This sounds like a gap in the curriculum that could be filled by grad students. I'm not in CS, but I know that the bioinformatics students have organized a course that covers some basics of the unix command line tools, probably because data conversion is a big part of most…
dubyaView on HNParent context