Research Software Developer, C4DM - position statement

A short summary of the responsibilities of a Research Software Developer within the Centre for Digital Music at Queen Mary, University of London.

The position of in-group Research Software Developer (also termed Research Software Engineer or RSE) has five facets:

Operate in a consultative capacity on funded research projects. Software development is an unavoidable activity and a cost in many research projects, even those in which software is not considered a primary outcome. As a non-research supporting activity often carried out by non-professional practitioners, software development is essentially a source of risk and of potential threats to a successful project. The involvement of a software engineer mitigates that risk through assistance with tool selection and use, advice about the best use of development time, and troubleshooting in development roadblocks, as well as hands-on development.
Manage group infrastructure and relationships with third-party infrastructure providers. The C4DM uses an in-house software project hosting platform (https://code.soundsoftware.ac.uk), which is open to audio and music researchers throughout the UK and which is maintained by a research software engineer within the group. In other institutions, the same role may be carried out by an external service which an RSE may also manage: for example, UCL have software engineers managing an institutional Github account.
Publish and maintain existing software. Research software often goes unpublished and is seldom maintained. It's not realistic to expect all software developed ad-hoc during research to be maintained, but it is important to ensure such software is made available in the first place. A software developer can help with packaging and release, and one who is familiar with the research field can then respond in cases where a piece of software is found to need updating to satisfy some demand. Besides pure research software, C4DM also publish a number of tools that are used by other researchers and in outreach, such as Sonic Visualiser, and applications like these start to lose their utility if they are not properly maintained.
Carry out blue-sky development work. In the case of C4DM, the Sonic Visualiser application arose from a "blue-sky" development rather than a necessity within a research project. It is not often possible to find enough developer time to do much of this, and end-user applications are often best left to commercial companies, but there are types of application (such as exploratory utilities relevant to the field, as Sonic Visualiser, or educational tools aimed at popularising an aspect of research work) which a research group may be well positioned to develop.
Assist in preparing funding proposals. The involvement of a developer can mitigate risk during a research project, and it follows that this should be made clear through the funding process before a project begins. Within C4DM we have named software developers as co-investigators on a number of funding proposals, something which has so far usually been well received in assessment, and have used developers to help clarify scope and timing for software components before a proposal is submitted. Relatedly, an in-group software developer can also help with recruitment for technical roles in a project following funding.

Tweets by @soundsoftwareuk

Recent notes

MLSP Prizes for Reproducibility: Winners announced!

Announcing the winners of the MLSP 2014 and SoundSoftware.ac.uk Prizes for Reproducibility in Signal Processing, organised by SoundSoftware.ac.uk in conjuction with the IEEE Signal Processing Society for the 2014 IEEE International Workshop on Machine Learning for Signal Processing.

SoundSoftware 2014: Videos now available!

The SoundSoftware 2014 workshop, our third annual workshop on software and data in audio and music research, was just as enjoyable as the previous two. Because so much research in this field ends up being expressed through software, a software workshop turns out to be all about the means by which research becomes useful and relevant to people other than the original researchers—fertile ground for interesting and thought-provoking talks.

The workshop videos are now available online at http://soundsoftware.ac.uk/soundsoftware2014, so if you weren't able to make it in person, catch up here!

Our third annual one-day workshop on Software and Data for Audio and Music Research takes place on the 8th of July 2014 at Queen Mary, University of London. The workshop includes talks on issues such as robust software development for audio and music research, reproducible research in general, management of research data, and open access. Read more here, clear your calendar, and register now!