As my group has grown over the past few years and I have more people writing software, I have started to progressively freak out more and more about how to make sure that the software is sustainable as students graduate and move on to bigger and better things. I am also concerned with maintaining quality of the software we are developing in a field where the pace of development/discovery is so high.
As a person who simultaneously (a) has no formal training in CS or software development and (b) believes that if there is no software there is no paper I am worried about creating a bunch of unsustainable software. So I solicited the advice of people around here who know more about it than I do and I collected my past experience with creating software and how I screwed it up. I put it all together in the Leek group guide to building and maintaing software packages.
The guide covers (among other things):
- When to start building a package
- How to version the package
- How to document the package
- What not to include
- How to build unit tests
- How to create a vignette
- The commitment I expect in terms of software maintenance
I put it on Github because I’m still not 100% sure I got it right. The policy takes effect as of now. But I would welcome feedback/pull requests on how we can improve the policy to make it better and reduce the probability that I end up with a bunch of broken packages when all my awesome students, who are much better coders than me, eventually graduate.comments powered by Disqus