Frequently, code used for generating scientific results is either not available, or not readily implementable/sufficiently understandable for reproducing results and/or building knowledge incrementally on top of them. This results in redundant work and, in the grand scheme of things, slows down scientific progress tremendously. Moreover, code that is not designed to be possibly re-used – and thus scrutinized by others – runs the risk of being flawed and thus produce, in turn, flawed results. Finally, it hampers collaboration – something that becomes increasingly important as people from all over the world become more inter-connected, more diversified and specialized knowledge is produced, and the mere amount of people working in science increases. To manage those developments well and avoid working in silos, it is important to have structures at place that enable people to join forces, and respond to and integrate each other’s work well.
Science at large it is still operating within the general doctrine of doing work alone rather than collaboratively. This may hold for Artificial Life (ALife) in particular, as for cultural/scientific practice reasons, special value may be placed on individual rather than collaborative research outputs. At the same time, there is a growing need within the Alife community to foster collaborative patterns and meet reproducibility and open science standards. This includes
- ensuring that results are correct (by using, e. g., unit testing) and reproducible (e. g., by using configuration files), and documentation is sufficient,
- ensuring the correctness of software at scale (by, e. g., scaling up unit testing),
- ensuring software can be run in various environments (by, e. g., using containers), and that it is improved and managed over its lifetime,
- knowledge about software architecture and design which helps avoid major code refactoring following minor changes to the code base,
- open-sourcing a project on, e. g., GitHub.
This carpentries-style tutorial will address a selection of the major points mentioned above. As the tutorial is still under construction, the foci/exact contents are yet to be determined.
For folks looking for educational resources beyond 90 min tutorial time, I recommend having a look at this course – which the tutorial described here certainly takes inspiration from – from the Carpentries Incubator, involving an estimated time-commitment of 2-4 hours spanned over 5 days.
This tutorial is targeted to anyone who has basic programming skills in Python, and aims to learn more about best practices and new ways to tackle research software development in ALife. It is suitable for all career levels – from students to (very) senior researchers for whom writing code is part of their job, and who either are eager to up-skill and learn things anew, or would love to have a proper refresh and/or new perspectives on research software development.
Overall, I aim to contribute to better software and collaborative practices – and therefore better research – in the field of ALife.
I get support for this tutorial from my fellowship at the Software Sustainability Institute.