By Toby Hodges, EMBL, Roman Klapaukh, UCL, David McKain, University of Edinburgh, and Tobias Schlauch, DLR

WSSSPE members recognise the value of good practice in software development and the benefits of robust and reproducible code in research. The adoption of such practice requires an investment of time, energy, and money, and unfortunately it can be difficult to convince research scientists that this investment is worthwhile. Several initiatives already aim to encourage good practice in research software development, for example, Software Carpentry, the Software Sustainability Institute, the internal Software Engineering Initiative at the German Aerospace Center (DLR), and the Bio-IT project at EMBL. However, some research groups have remained difficult to reach.

Different approaches can be targeted at different levels and career stages. The majority of these share a common theme of support for the local research community.

For those at an early career stage, adoption of good practice can be encouraged by the availability of training, resources, and tools that reduce the barrier to entry. Similarly, building connections and a support network to enable discussion and knowledge sharing can be very empowering for early-career researchers and can help to spread good practice.

At later career stages, for example at the postdoctoral level, motivation is likely to come from an increasing acknowledgement of the connection between good practice and increased publication rate and quality, as well as funding availability. There are several strategies for achieving these goals.

Training

Training in good software development skills is vital for the uptake and maintenance of good practice in a research community. Good, easily available training helps researchers to gain the skills and knowledge required to adopt good practice. In addition, it helps to establish a common, consistent approach to software development, which can benefit collaboration and the longevity of projects. Several good training initiatives already exist for research software development but locally-provided individual training is equally important.

Additionally, if a group contains a handful of people who already possess knowledge in good software development practice, these people can help to provide “micro-training”, integrated into day-to-day work, for example in the form of code reviews. However, the success of such peer-oriented approaches relies on trust and mutual respect between colleagues, which can be affected by various aspects such as a lack of formal training of the reviewer, or a lack of confidence in the reviewee.

Community building

Community building is a crucial activity for reaching out to research groups. A good first step is to form an interest group of people willing to push the topic in their specific research groups. However, there are also further, regular activities required to keep these communities “alive” and growing. Sometimes, depending on the research organisation, management support is also a crucial success factor.

A concrete example is the community that has been established at German aerospace centre DLR. DLR is a large research organisation consisting of 33 institutes conducting research in different areas. As a first step DLR established a software engineering network, which consists of representatives of all DLR research institutes. The network actively discusses and initiates central activities to support researchers, and runs further central activities to directly involve researchers. Every year, an experience exchange workshop is held that focuses on a specific software development topic such as software testing, open source, embedded systems, or software architecture. The idea of the workshop is to provide knowledge, experience exchange and networking, as well as encouraging direct contribution from researchers. Furthermore, there is a dedicated, moderated Wiki space for exchanging knowledge and experience about software development. Everyone at DLR has access to this and can easily contribute by improving articles, contributing a how-to, or simply adding comments. In particular, the Wiki space provides a blog that serves as an internal news channel and an “Ask a question” section to ask for help and advice. In addition to these organisational activities, the members of the software engineering network further drive improvement in the context of software development within their institutes and research groups.

Another concrete example, established at the European Molecular Biology Laboratory (EMBL), has been the concept of a coding club. It is marketed as a kind of “Christmas special” event to get people into doing paired code review on a special coding challenge – not people’s own code. However, we would suggest that such a challenge needs to be facilitated properly so that people feel safe getting involved.

Finally, good development practice within a research group could help to connect PhD students, as many of them often work in relative isolation. An interesting concept in this context is “inner source”, which proposes the joint development of software within an organisation following open source principles. This concept could be useful for developing common scientific frameworks that directly involve interested researchers or PhD students.

Tools and services for software development

In addition to discussing and teaching good practice, it is important to make adoption of this as simple as possible. One aspect of this is the provision of easy-to-use tools offering basic support for software development, such as version control and issue tracking, and collaboration including code review, activity feeds, comments and notifications.

One particular example is the open source software forge GitLab, which has been successfully deployed in different organisations and is considered to be an attractive option for a number of reasons. The software forge provides version control via the popular Git version control system. In addition, it adds and integrates additional features such as issue tracking, collaboration tools and support for continuous integration. Project owners have control over the visibility of their work and the features they use.

One particularly positive aspect of having established an internal software forge is that people within an organisation may feel more comfortable putting their code into it. For example, since the service runs internally, it is easier to find people to help get started with it. In addition, licensing and copyright conditions are easier to satisfy. Finally, the software forge provides the necessary infrastructure to start inner source software projects. That is to say, people have a safe internal place to start working together on software of interest.

In addition to a software forge, value-added tooling and functionality such as automated code quality checks can also be worth offering. However, it could be argued that such functions should be not be forced on users, as they may feel their code is always being criticised, potentially resulting in disengagement.

Regardless of the options taken, we would recommend using an iterative approach, focusing on the delivery of one tool or service at a time. However, it is also important to realise that a “build and they will come” approach does not usually work, so the initial service roll-out needs to be planned carefully, and a promotion and training campaign will also be required to nurture the new service.

Unfortunately, there can be no “right” or “golden” approach as it heavily depends on the organisation that surrounds you. However, there are some common themes like providing training, bringing interested people together, and establishing tools for developing and collaborating on software. While it is worth pointing out that these activities work best in combination, most of the approaches we discussed originally started out small and have been developed and progressed incrementally.

Finally, we would be very interested in hearing about other approaches and experiences. So please let us know via email!