Scientific software is often developed by a single person, usually a graduate student or a postdoc. The code might run just fine on their own computer, but what if someone else wants to run it? More often than not, scientific code is poorly documented, might work in unexpected ways (or not at all), rely on nonexistent paths or resources, or might simply fail to reproduce what was published in the paper. To avoid many common challenges associated with scientific code, Morgan Taschuk from the Ontario Institute for Cancer Research (Toronto, Ontario, Canada) and Greg Wilson from the Software Carpentry Foundation (Austin, TX) have come up with a list of ten simple rules.
