Can Research Software Engineers help measuring behaviour?

Presenters: Raniere Silva and Caroline Jay, University of Manchester, UK

Time: Wednesday 6th June, 15:50 - 17:00, G27


Research Software Engineers (RSE) is the term that started to be used in the United Kingdom around 2012 to denominate people in a variety of roles who understand and care about both good software and good research. It is an inclusive definition that covers a wide spectrum of people from a researcher who is primarily focused on getting results for papers but does a lot of programming to a software engineer who just happens to work for a research organisation. Somewhere in the middle lies the RSE who may actually have that as their job title and/or might work for one of the fast-growing set of Research Software Groups.
The purpose of this discussion is to: examine and discuss the contribution of research software engineers to behavioural science studies; determine the impact of research software engineers in a behavioural researcher group; and to make recommendations for the inclusion of research software engineering positions in grant proposals.
We will start the discussion with a short lecture on the growth of the United Kingdom Research Software Engineer Association and some examples of work done by RSE that might be interesting to behavioural researchers followed by an interactive discussion on the topic. At the end of the discussion, we will have data to produce a short paper with our recommendations.
The discussion will use some or all of the following questions:
1.    What research software did you use in your last paper? Make a list.
2.    How many of the software applications on your list are open source?
3.    How many of the software applications on your list have some documentation?
4.    How many of the software applications on your list have any kind of support forum? This can be a email address, a mailing list, web forum, a Q&A website or something else that you can turn for support.
5.    Does the software you use do exactly what you want, or could it be better?
6.    Do you, or members of your group, develop your own software? This might include anything from scripts for analysing data (e.g. R or Python scripts) to websites.