My colleague Jeremy Yates made the following comment to an earlier post. I thought it was interesting enough that it deserved a post and reply of its own:

An update from the coalface of the National E-I Project Directors Group. There is a major report being written for us and RCUK that looks at the practical issues of support and training including funding it. We hope this advice is made part of the RCUK E-I Strategy.

While we can at least make sure all the procedures and policies are right; the real task is to convince PIs (like me) of the utility of non-subject domain staff, not under my direct supervision, carrying out software tasks for my research.  The last week has provided me with several examples of a lack of trust/desire to retain control.  It’s taken a long time to wean people off having their own hardware; software is another matter in that it really does represent for many their IP and product – it’s personal.

At the heart of this though is the question “Just what is research software support?”

Some definitions I have heard sound a lot like “research” and seem to be combined with efforts to charge fEC on posts.   As I go deeper into this I’m learning the words that cause friction – Developer is benign in IT, but in research it is synonymous with Researcher; Engineering is, well, a research area.  We find ourselves forced back into terms that have become pejorative, such as “consultant”, or lower-grade such as “technician”. Perhaps we have to use older words such as Specialist or Expert.  Certainly the phrase “scientific programmer” is starting to reappear.

As ever this is going to be rather a long haul.   The need for a new and common lexicon between IT and researchers is the least of it.

— Dr Jeremy Yates, Director, STFC DiRAC HPC Facility,

We’ve been thinking a great deal about these questions in the UCL team: in our view we are professionals who are part of the research community, but are not pursuing our own research directions, instead acting as expert collaborators. This role, integrated within the modern multidisciplinary research effort, with the ability and experience to understand and contribute to research at the forefront of human knowledge, but as collaborators, not research leaders, is becoming more important as the set of skills needed to carry out effective research expands. This professional expert collaborator role, will, I think, apply in the 21st century not just to programming, but to other research contributions, including statistics, visualisation, and technical writing.

When we work with a research team, we take a collaborative, hands-on approach, trying to work with the processes, tools and ways of working that are comfortable for that team, while suggesting ideas from agile software development practices that may be helpful. By embedding ourselves within the culture of the group we are working with, we try to ensure that academic colleagues feel a strong sense of ownership for the code we produce together, while allowing our skills to diffuse into research groups. We do not follow a contractual, delivery-oriented approach. The feedback from the groups we have worked about this approach has been very positive.

We use the terminology Research Software Developer and Research Technologist, to indicate that we are specialist software developers, with the expertise, background, and intellect to engage deeply with advanced research. As I was quoted saying in a recent issue of the Times Higher Educational Supplement:

“It’s not our job to understand the science as much as the principal researchers, but you can’t do good software engineering without an understanding of what the programs are supposed to do. That is what we bring compared with the general software engineering marketplace.”