Best practice

DH.pngBy Becky Arnold, University of Sheffield

On the 2nd of May 2018, David Hubber, a postdoc at Ludwig-Maximilians-Universität Munich, gave a seminar on Long-term Software Development for Scientists, as part of a series of talks around good practice at the University of Sheffield. David discussed how to structure code efficiently, code module design, decoupling strategies and test-driven development.

I’ve had the pleasure of meeting David previously— we’re both astrophysicists working on simulations of star forming regions. In particular David has a great deal of experience in working with big codes that span tens of thousands of lines. While my own work is of a smaller scale I and I think many researchers are familiar with writing programs that start small and quickly evolve into a huge unmanageable mess.

David discussed the dangers of “the blob” and “spaghetti code”, before going on to cover strategies to avoid them. Some of these strategies were stylistic, he described how keeping consistent with style choices in your code makes it easier to understand for your future self and others, thus making it more maintainable.

He also discussed how comments (while absolutely vital) can also be something of a double edged sword if misused. Excessive comments can…

Continue Reading

Software Sustainability Institute fellow Becky Arnold is arranging a series of talks on good coding practice and related topics. The first session will take place on the 2nd May at Sheffield University. The talk will be in the Hicks building, lecture theatre 6 at 3:30 pm. 

David Hubber (Ludwig-Maximilians-Universität Munich) will be giving a talk about how to structure code efficiently. He will also discuss code module design, decoupling strategies and test-driven development.


All are welcome and there's no need to register.
 

Further information and information on other upcoming sessions is available at the…

Continue Reading

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
Subscribe to Best practice