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:

  1. 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.
  2. Manage group infrastructure and relationships with third-party infrastructure providers. The C4DM uses an in-house software project hosting platform (, 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.
  3. 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.
  4. 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.
  5. 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.