Best practice

groupc.pngBy Stuart Grieve, Research Software Developer, University College London, Eike Mueller, Lecturer in Scientific Computing, University of Bath, Alexander Morley, DPhil in Neuroscience, University of Oxford, Matt Upson, Data Scientist, Government Digital Service, Richard Adams (Chair), Reader, Cranfield University, Michael Clerx, Post-doctoral researcher in Computational Cardiac Electrophysiology, University of Oxford.

This blog post was motivated by a discussion amongst academics and research software engineers from different disciplines on the challenge of writing good, sustainable software in teams with different backgrounds. Specifically, how can a mixed team of, say, scientists, librarians, engineers and project managers be encouraged to write good software together?

Our discussions led us to two broad recommendations: first, to ensure that research software…

Continue Reading

2011.11.15_building_software.pngBy Adam Tomkins (Chair), University of Sheffield, James Grant, University of Bath, Alexander Morley, University of Oxford, Stuart Grieve, University College London, Tania Allard, University of Sheffield.

There is a growing interest in the adoption of software best practices in research computing and allied fields. Best practices improve the quality of research software and efficiency in development and maintenance as well having the potential to deliver benefits outside software development.  However, this interest in these methods is not universal and there is a possibility that a drive for best practice could lead to a widening divide between those who embrace this change and those who do not. It is therefore vital that Research Software Engineers (RSEs) work closely with domain specialists, to bridge this divide and attempt to meet the challenges of efficiency and reproducibility:

  • How do we…

Continue Reading

3857596_b61f5c8d78_z.jpgBy Sammie Buzzard, University College London; Martin Donnelly, University of Edinburgh.

Introduction or why does this matter?

Whether our involvement in software is in developing it from scratch, building upon existing code, reusing or repurposing someone else’s work, or preserving it (for ten years or until the end of the world, whichever comes first), good software practices benefit us all. This could range from basic version control for an undergraduate’s first coding project to passing well-documented software from one research project to its successor, but the best way to motivate people to improve their practices will be highly dependent on the individual and their circumstances and drivers.

Additionally, appealing to the individual is effective but it doesn’t scale—there are simply too many people involved in research software for a small community of advocates to reach on an individual basis. There are also more wide-ranging actions that could be taken, for example by journals and funding bodies, that could catalyse change within the research software community as a whole. Like any bridge, it is  a good idea to start building from both ends...

So what can we do at an individual level?

In common with most other…

Continue Reading

Best practice for scientific softwareBy Damien Irving,  climate scientist

This post was originally published on the Dr Climate blog.

Code written by a research scientist typically lies somewhere on a continuum ranging from “scientific code” that was simply hacked together for individual use (e.g. to produce a figure for a journal paper) to “scientific software” that has been formally packaged and released for use by the wider community.

I’ve written at length (e.g. how to write a reproducible paper) about the best practices that apply to the scientific code end of the spectrum, so in this post I wanted to turn my attention to scientific software. In other words, what’s involved in turning scientific code into something that anyone can use?

My attempt at answering this question is based on my experiences as an Associate Editor with the Journal of Open Research Software. I’m focusing on Python since (a) most new scientific software in the weather/ocean/climate sciences is written in that language, and (b) it’s the language I’m most familiar with.

Hosting

First off, you’ll need to create a repository on a site like GitHub or Bitbucket to host your (version controlled) software. As well as providing the means to make your code available to…

Continue Reading

GUADECBy Raniere Silva, Software Sustainability Institute, David Pérez-Suárez, University College London.

Last year Raniere found out that the GNOME User and Developer European Conference (GUADEC) 2017 would be hosted in Manchester and that he should attend. Early this year, during Science Together, Raniere mentioned GUADEC to David Pérez-Suárez and we agreed to show up at the conference to find out what we could learn from GNOME about onboarding newcomers and best software development practices.

Onboarding Newcomers

GUADEC

All open source projects struggle with onboarding newcomers. And, most of the time, driving yourself to the first contribution is a journey that will have old source code, out-of-date documentation, undocumented culture and other rocks on the way. Thankfully, many contributors to open source are working collaboratively with other…

Continue Reading

Europython 2017By Alice Harpole, University of Southampton

Coding is often seen as a tool to do science, rather than an intrinsic part of the scientific process. This often results in scientific code that is written in a rather unscientific way. In my experience as a PhD student, I've regularly read papers describing exciting new codes, only to find that there are number of issues preventing me from looking at or using the code itself. The code is often not open source, which means I can’t download or use it. Code commonly has next to no documentation, so even if I can download it, it's very difficult to work out how it runs. There can be questionable approaches to testing with an overreliance on replicating "standard" results, but no unit tests exist to demonstrate that the individual parts of the code work as they should. This is not good science and goes against many of the principles of the scientific method followed in experimental science.

In the following sections, I shall look at how we might go about writing code in a more scientific way. This material is based on the talk I recently gave at Europython 2017 on Sustainable Scientific Software Development.

Scientific code

Continue Reading

Good coding practiceBy Sanjay Manohar, University of Oxford, and Software Sustainability Institute fellow

When you try to distil years of experience into words, something is always lost. How can you convey the basic principles of a practical art in a seminar? Teaching coders how to code well is challenging because each person starts with a different set of experiences, a different skill set, and a different end goal in their programming journey. Yet there is something that brings them all together: a passion to improve their code to broaden the set of techniques they have in their toolbox.

As a teacher, it is crucial to remain aware of what students do and do not understand yet. A set of assessment techniques is part of the armament of every educator and allows the use of the most appropriate level of language, criticism and sophistication. These formative tools also give students the feedback they need to see their own limitations and measure themselves against.

On 10th April 2017, I held a seminar on good coding practice for neuroscientists. It was at the British Neuroscience Association Festival of Neuroscience, a national meeting involving neuroscientists of every kind from around the country. In a small seminar room in the convention centre, forty excitable scientists crowded…

Continue Reading

Best coding practicesBy Sanjay Manohar, University of Oxford, and Software Sustainability Institute fellow.

We have a problem in neuroscience. The complexity of data analysis techniques increases every year. With each increase in complexity comes an increase in the possibility of error. We have already been plagued by such problems, which have been reported on the internet and in the news. With increasing quantities of code being written, these problems seem unlikely to subside. How can we address the root of the problem?

In a questionnaire I regularly give to my students, one recurrent and ominous statistic always emerges: neuroscientists are, by and large, taught by each other to code. A PhD student is taught by his postdoc, who is in turn guided by her PI, who herself learned to program on the job with help from colleagues. Nobody in the loop has been formally taught coding practices, or implements the kinds of guidelines or conventions that are commonly imposed when programming in industry. This, I believe, is a central part of the problem.

I see a…

Continue Reading

Readable.jpgBy Mike Jackson.

Readable source code is vital

If our peers are to quickly and easily understand our source code, it must be readable. The Software Sustainability Institute can provide advice and guidance on producing readable source code. We can even review your source code to see whether it can be improved.

Why write this guide?

With increasing requirements for researchers to make their source code available, we thought this guide would be a useful resource for researchers developing software, to ensure that the code they produce is understandable by their peers.

Why is readable source code important?

Source code is designed for us. It may end up being processed by a machine, but it evolves in our hands and we need to understand what the code does and where changes need to be made. We may understand our code now, but what about six months or a year from now? Readable code helps us to reaquaint ourselves with what we wrote and why we wrote it.

Our code may embody some unique aspect of our research. Readable code can help our fellow researchers to understand what we've done and so to assess whether this aspect of our research is correct. Or, to put it another way, would we rather have a peer spot a problem now, or, six months later when we've published a paper based on flawed results produced using our software?

There's also our image to consider. If our code is badly laid out, messy and cryptic, others will assume that it is also buggy…

Continue Reading

Typing BioJSby Manuel Corpas, Project Leader, ELIXIR-UK Technical Coordinator, CorpasLab, The Genome Analysis Centre (TGAC).

In this blog entry we discuss the outcomes of the recently held JavaScript for Visualisation Workshop, The Genome Analysis Centre (TGAC), Norwich, UK, April 21-22. This workshop brought 26 attendees from around the UK and the continent. The event was open to both core technical members and developers not currently involved in the BioJavaScript (BioJS) project. The workshop was facilitated by Software Sustainability Institute 2016 fellow Manuel Corpas to promote software best practices and the latest standards in JavaScript, inspiring the future technical roadmap for the BioJS community.

The Need for this Workshop

JavaScript has become the de facto language of the web. Console-like interactivity is now common place in most web applications and sites. Online collaboration plays an important role in research, enabling scientists to share and disseminate results regardless of geographical location. The data-intensive field of bioinformatics greatly benefits from JavaScript technologies applied to visualisation of biological datasets.…

Continue Reading
Subscribe to Best practice