blog

A guest post by Manuel Corpas, Scientific Lead at Repositive, formerly of The Earlham Institute & ELIXIR-UK. 

We all recognise the fact that good practices when developing code are a positive thing. But when reality hits home, the rush of moving on to something else strikes or simply when the all too common procrastination thought “I will do it later” takes hold, it is easy to conveniently forget some common practices.

The little demon on our left shoulder tells us that spending the effort to place our code in a versioning controlled system, reusing existing software or commenting at all do not really matter. This is the trap in which we can fall when releasing our code, only caring to publish quickly and doing the least to make it sustainable, scalable and easy to maintain.

In order to draw up some guidelines, the ELIXIR Good Software Metrics Working Group gathered developers from around Europe involved in ELIXIR to come up with a simple list of metrics that can help make software for the life sciences more sustainable. In collaboration with the Software Sustainability Institute, we brought experts from a number of countries to come up with a minimum set of guidelines that are recommended within and without the ELIXIR network when developing software.

At the meeting, the group brainstormed potential metrics, their impact and applicability. The experts aimed to be as inclusive as possible, as long as each suggested metric had potential for impact. After the discussion, we identified a set of 17 topics that are critical for software development good practice.

From these 17 topics, we came out with 10 good practices that we recommend as basic indicators for sustainability of life sciences software, and have published them on F1000Research. We stress that the main way to encourage good software practices involve their monitoring and accountability, given that such activities are funded with public money and hence are property of the European tax payer.

These ‘Top 10 Good Practices’ should be considered as an initial view of what the community considers important. We do not, however, want to be prescriptive. The metrics we propose can be both qualitative and quantitative. Although quantitative metrics are easier to track, it is also important to capture qualitative characteristics such as existence of automated testing or compliance with community standards.

The article summarises an initial response from the working group established to assess the problem of evaluating metrics for software development good practices. We expect it to be modified in future versions as more experts join this group and new challenges emerge with evolving technologies and life science software needs. It is our duty as researchers and developers to comply with guidelines that maximise the use, reuse and sustainability of the software we develop, regardless of time constraints and pressures to publish.