Software and research: the Institute's Blog

By Mark Woodbridge, Research Software Engineering Team Lead

This is the first in a series of blog posts by the Research Software Engineering team at Imperial College London describing activities funded by their RSE Cloud Computing Award. The team is exploring the use of selected Microsoft Azure services to accelerate the delivery of RSE projects via a cloud-first approach. This post was originally published at the Imperial London College Research Software Engineering team blog. 

A great way to explore an unfamiliar cloud platform is to deploy a familiar tool and compare the process with that used for an on-premise installation. In this case we’ll set up an open source continuous delivery system (Drone) to carry out automated testing of a simple Python project hosted on GitHub. Drone is not as capable or flexible as alternatives like Jenkins (which we’ll consider in a subsequent post) but it’s a lot simpler and a suitable example…

By 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…

By 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…

By Sam Cox, University of Leicester, Richard Adams, Cranfield University, Eike Müller, Met Office.

The role of software in research and who writes it

From an institutional level down to teams and even individuals, research today is heavily reliant upon software and particularly upon bespoke computer code which solves specific scientific problems.. This creates a huge demand for software creation and maintenance. Traditionally, this has been the responsibility of post-docs and postgraduates. But while they play a crucial role in the success of the research group, the indirect nature of the translation of their work into papers (particularly the maintenance and update work to keep on keep the software fit-for-purpose under changing scientific requirements) can leave the individual researchers at a disadvantage—they have less time for the more traditional work of running experiments and writing papers. This in turn has an effect upon their career progression, which hinges on clear metrics for success.

As a result, one major issue is how to identify what ‘…

By 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…