Software and research: the Institute's Blog

Latest version published on 28 May, 2018.

38523074811_210bcc3ed4_z.jpgBy Mike Jackson, Software Architect, The Software Sustainability Institute

On the 7th March, Jisc and the Software Sustainability Institute ran a Software Deposit and Preservation Policy and Planning Workshop at Jisc’s Brettenham House in London. This was part of an activity, funded by Jisc, to provide software deposit and preservation guidance, in particular to develop use cases and workflows for software deposit via Jisc's Research Data Shared Service (RDSS). A draft report on the workshop is now available.

Read the draft report, available on Zenodo (doi:10.5281/zenodo.1250310).

We also invite feedback on the report. In particular we welcome additional sources of information and other resources relating to software deposit and preservation, corrections, clarifications and additional suggestions as to future work. If you'd like to provide feedback, then please add this to our copy of the report on Google Docs, noting your full name and affiliation so we can acknowledge you…

Continue Reading

Latest version published on 25 May, 2018.

5518280677_581f2a1e3f_z.jpgBy Naomi Penfold, Nikoleta Glynatsi, Yo Yehudi, James Baker, Steve Crouch

This post is part of the Collaborations Workshops 2018 speed blogging series.

As science becomes more reproducible, how do we ensure that the work we do today can be interrogated in the future as a matter of historical record? We discuss this from the perspective of researchers, research software engineers (RSEs) and the publisher, and offer responses to five questions central to archiving code and software. We note first that our perspectives come from an expert group—not the average researcher.

Why archive and for whom?

People change. It’s not just that code evolves and packages change, in turn influencing the choice of methodology, but that people and their preferences change as well. Regardless of how research will be done in 10 years time, it’s critical that methods used to derive a result in the past can be inspected and interrogated. No matter how much the code changes, the results shouldn’t if you are doing things right.

The author and reuser are perhaps—and should be—indistinguishable; that is authors are one potential future reuser, and that consideration should be taken into account.

How do we make archived code and software meaningfully reusable?

Code should be readable, and at best meaningfully reusable. Even if we…

Continue Reading

Latest version published on 24 May, 2018.

3631348557_7d705f856e_z.jpgBy Andrew Walker, Sam Mangham, Robert Maftei, Adam Jackson, Becky Arnold, Sammie Buzzards, and Eike Mueller

This post is part of the Collaborations Workshops 2018 speed blogging series.

Good practice guides demand tests are written alongside our software and continuous integration coupled to version control is supposed to enable productivity, but how do these ideas relate to the development of scientific software? Here we consider five ways in which tests and continuous integration can fail when developing scientific software in an attempt to illustrate what could work in this context. Two recurring themes are that scientific software is often large and unwieldy—sometimes taking months to run on the biggest computer systems in the world—, and that its development often goes hand in hand with scientific research. There isn’t much point writing a test that runs for weeks and then produces an answer when you have no idea if the answer is correct. Or is there?  

1. Test fails but doesn’t say why

Screen%20Shot%202018-05-24%20at%2010.00.37.png

This one kind of explains itself. If the test doesn’t tell you what’s wrong, how are you…

Continue Reading

Latest version published on 23 May, 2018.

7838388322_8883573e4e_z.jpgBy Martin Callaghan, University of Leeds, Daniel S. Katz, University of Illinois, Alexander Struck, Cluster of Excellence Image Knowledge Gestaltung, HU-Berlin, and Matt Williams, University of Bristol, 

This post is part of the Collaborations Workshops 2018 speed blogging series.

This blog post is the result of a discussion group during the Collaborations Workshop 2018 organised by the Software Sustainability Institute. We talked about some national and institutional efforts being made to establish RSE groups and positions and are writing this blog to share our thoughts. The most successful of these RSE efforts have come from within UK universities. We believe sharing strategies and case studies on how to implement pilots should help grassroots movements and support…

Continue Reading

Latest version published on 22 May, 2018.

4825668491_2d9d7902c2_z.jpgBy M. H. Beals, Catherine Jones, Geraint Palmer, Mike Jackson, Henry Wilde, John Hammersley, Daniel Grose, Robin Long, Adrian-Tudor Panescu, Kirstie Whitaker

This post is part of the Collaborations Workshops 2018 speed blogging series.

What does reproducible mean? Who do we want to help and support by making our research reproducible? At what point does non-reproducible research become good enough (and carries on to the highest standards of reproducibility?)

In our discussions during the first speed blogging session at the Software Sustainability Institute’s Collaborations Workshop in Cardiff in March 2018, we brainstormed criteria for judging the quality of reproducible research. What emerged were two clear messages: 1) We all have our own overlapping definitions of the desirable features of reproducible research, and 2) there is no great benefit in rehashing old discussions.

In this blog post we outline 9 criteria that can be met by reproducible research. We believe that meeting as many of these as possible is moving in the right direction. Source code and data availability are often seen as important requirements, but documenting what code is trying to achieve, which other software libraries are required to run the code, the greater research ecosystem, what lessons were learned in the development of the…

Continue Reading