Posted by s.aragon on 17 August 2016 - 2:26pm

By Simon Hettrick, Deputy Director 

On a beautifully sunny day in March 2012, a small group met at Queen’s College Oxford and challenged a long-standing problem: why is there no career for software developers in academia? They didn’t know it at the time, but this meeting led to a nationwide campaign that created a vibrant and rapidly growing community, and established a new role in research: the Research Software Engineer.

The lack of a career path for academic software developers wasn’t new back in 2012, but it had gone largely unchallenged. Many academics were aware of the importance of software to research; they could see that the people who created this software went largely unrecognised, and they were beginning to worry about the consequences of this oversight. What happens when something is so vital to research, yet overlooked and severely under-resourced? Concerns like these were raised at our Collaborations Workshop, and this led the group to meet and challenge them.

A new role is born

The group that rose to the challenge consisted of Rob Baxter, Ian Bush, Dan Emmerson, Robert Haines, Neil Chue Hong, Dirk Gorissen, James Hetherington and Ilian Todorov (I missed this now-historic moment because I was running the conference, but the notes are available). They realised that software developers lacked something more fundamental than just recognition—they lacked a name. In a short study in 2014, we investigated 10,000 academic job adverts, found 400 of them related to software development, and discovered that these boasted almost 200 different job titles! How can anyone get behind a role, if no one can even agree on what it should be called?

Deciding on a name isn’t easy. My own personal vision of hell would be being locked for eternity in a room full of academics trying to decide on a name for something. A name must be descriptive, yet short enough to be meaningful. It must differentiate, but can’t clash with the academic world view. It must be acceptable to both the people who use it and the university bureaucracy. Eventually, the new role was christened by fusing the two skills that make it unique: an understanding of both research and software engineering.

Members of the original group wrote a paper about Research Software Engineers which was presented at Digital Research later in 2012. It went beyond just identifying the problem and naming the role. It discussed the lack of a career path, the result of which is to lock software developers into a position with no opportunity of progression and almost nonexistent job security. It realised that this occurs because software is overlooked as merely “an uninteresting means of achieving interesting research”. Finally, it discussed research incentives and the way in which they act against good software development, and consequently how they act against providing support for software developers.

It’s not easy being seen

Papers alone rarely change the world. Real change comes from people, and it soon became clear that Research Software Engineers needed a community.

When we started the Software Sustainability Institute, we expected much of our work to be invested in software development. We could do some great work this way—still do in fact—but we knew that our impact would be severely limited if we relied only on our developers getting hands-on with problem code. A far greater change would result if we could change the way the research community thought about software. There’s another article on how this change came about, but the important thing is that it led to the launch of our policy team in January 2013. I lead the policy team, and this is where my work with Research Software Engineers began. There was really no competition when it came to choosing our first campaign. If we could support the rise of expert software developers in academia, there would be an accompanying growth of reliable, well-engineered research software—and the impact of that would be huge.

Raising the profile of Research Software Engineers was not going to be straightforward. How do you draw attention to a role, when no one knows about it—not even the people who inhabit the role? Fortunately, by this stage the Institute’s website was popular so we had a custom-made audience for this news. We benefitted from some press interest, especially from Chris Parr at Times Higher Education and Adam Smith at Research Fortnight, who both took a chance on an article about this fledgeling community. We also began to talk incessantly about Research Software Engineers: no conference or meeting was safe, we’d always force the agenda to accommodate a discussion on RSEs.

Support for our cause was near universal, but there were a few detractors. Some people felt that academia had managed just fine over the last couple of thousand years, so why change now? There were some who could not see a software developer as anything but a technician. I must admit that I felt this was snobbery not just about software developers, but also about technicians. Some argued that the problem was simply too big to solve. It would require a change from researchers, funders and a whole swathe of universities (and their separate finance and HR departments). I’ve never agreed with this black-and-white approach to success. I’ll be ecstatic if we completely solve the problem of supporting RSEs, but I’ll be happy with every step we make towards improving it.

A community is founded

From the very beginning, we had the support of some vocal proponents of the RSE cause, without whom the campaign would not have been possible. We spent 2013 campaigning alongside Chris Cannam, Dirk Gorissen, James Hetherington, Caroline Johnston and Mark Woodbridge. By the end of 2013, we felt confident that we had built up enough interest to run a first workshop for RSEs. This took us back to the University of Oxford, this time at the Oxford eResearch Centre, where we were joined by 56 people who, even at this early stage in the campaign, had identified as Research Software Engineers.

We were lucky to secure Mark Hahnel, the founder of Figshare, as the opening speaker. Apart from being an engaging speaker with a fascinating history, Mark was an interesting case study. His success with software developed during his PhD took him out of academia—he is no longer a Research Software Engineer—and this is a path that many RSEs have followed. Is it inevitable that an RSE must leave academia to further their career?

I’ve often been challenged about the relationship between RSEs and universities. Surely our main goal is to produce a trained workforce for the nation, not to selfishly protect our Research Software Engineers from industry? I completely accept that we should be producing skilled developers for industry, but I can see no reason why we should not be able to retain some: the ones who are evidently interested in a career in research. Industry will always pay more, but no one enters academia because they want to get rich. People work in academia because they love the challenge of understanding the world and how it works. What’s more, if Research Software Engineers could exist in academia as easily as they exist in industry, then they could choose to pursue a career in either domain—or even better—in both. A Research Software Engineer who has learned the best ideas from industry and academia will be a benefit to both domains.

I closed the first RSE workshop with a question to the audience: would they like us to represent them in academia? The result was unanimous, and the UKRSE Association was born the following week. We opened membership with a concern common to all new ventures: would anyone join? There was an initial bump up to 50 members in the first week, and since that time membership has risen steadily up to 633 today with no signs of growth abating. After talking to many of our members, I was shocked at how many thought they were the only person conducting this highly valued but unrecognised work. The strength of the UKRSE Association is that it shows RSEs they are not alone.

In July 2014 we received an unexpected boost for the campaign. Completely out of the blue, Ashley Towers tweeted:

Yay my new job title is now official - Research Software Engineer - big thanks to @SoftwareSaved for starting the movement :-D

— Ashley Towers (@ashleytowers) June 3, 2014

It was first time that someone completely unknown to us had aligned themselves with the RSE role. Not only were people identifying with the ideas of the RSE campaign, but they were also choosing to go through the arduous task of changing an academic job title. This was a big win.

A sustainable, democratic community

The Software Sustainability Institute played an important role in founding the UKRSE Association and getting it running, but to make the association sustainable, it needed to be community led. Through 2014 we had run the association as a benign dictatorship. It was time to become democratic. Handing over responsibility for this rapidly growing community to a new committee was not going to be easy. We held our first AGM and received nominations for the committee from some incredibly talented RSEs: James Hetherington and Mark Stillwell shared responsibility for chairing, and they were joined by Jonathan Boyle, Dirk Gorissen, Robert Haines, Caroline Johnston, Florian Rathgeber, Adam Witney, and myself now in an ex officio role.

The first AGM was held at King’s College London. Kenji Takeda from Microsoft Research was quick to recognise the importance of the RSE Community, and this started what has been a long and fruitful collaboration with Microsoft Research. They were soon followed by Maudsley Digital, Github, Amazon, Google and Fitbit. All this new interest added a lot of pressure to the event. Half an hour after opening the AGM, I found myself desperately improvising as I talked to a very large room populated with influential sponsors and five, lonely looking RSEs. Unknown to me, a major signalling problem had caused delays across London. By 10.30, an hour later than planned, the room was packed with 74 RSEs, and my heart rate began a slow return to normality.

Following the AGM, the new committee took over the running of the UKRSE Association and in doing so we took our first step towards becoming a sustainable community.

A home in academia

Few research groups are large enough to support a Research Software Engineer working full time, but nearly all research groups require help from one. To solve this problem, a new model was proposed: the Research Software Group. This pools RSEs into a single group and allows researchers to hire them only when they are needed. It provides a flexible and cost-effective service for researchers, and it focuses the huge,but fragmented, demand for Research Software Engineers. This focussing allows a Research Software Group to sustain long-term careers. It also allows the group to grow to a size where a hierarchy is required, and this provides a promotion path. The first of these groups was pioneered at UCL with James Hetherington taking the lead.

Based on the success of the UCL group, the following years saw new Research Software Groups created by Robert Haines at the University of Manchester, Mike Croucher and Paul Richmond at the University of Sheffield, Christopher Woods at the University of Bristol and by John Robinson and myself at the University of Southampton. Interest continued to grow across the UK, and many people began to investigate how to set up their own group. Any academic will tell you how difficult it is to set up a new group in academia, but it’s child’s play compared to setting up a new group consisting of people who aren’t even recognised by academia. The leaders of the established groups realised that their expertise would be invaluable to anyone looking to set up a new Research Software Group. This led to the creation of the Research Software Group Leaders Network, which met for the first time at the University of Southampton and has met every six months since.

The Southampton Research Software Group is approaching its first birthday. In that time, we’ve completed a handful of projects and secured enough future funding to recruit an additional staff member. Demand for our services far outstrips the availability of our staff, and all evidence points to the group growing considerably over the coming years. This experience mirrors that of the more established Research Software Groups, some of which now number 10–15 RSEs. The incredible demand for services is common to all groups—new and old. “Prediction is very difficult, especially about the future”, but I can confidently forecast the growth of Research Software Groups, both in size and number.

One does not simply walk into a Research Software Group

We have benefitted over the years from the continuing support of the EPSRC, and especially from Susan Morrell, Louise Tillman, Iain Larmour and Eddie Clarke. The EPSRC saw the need for the RSE role back in 2012 and have provided expertise, advice and support ever since. In 2015, they made easily the greatest step towards embedding the RSE role in academia by funding a Fellowship.

The Fellowship provides five years of funding for a Fellow and a staff member, which is the initial support needed to set up a Research Software Group. Demand was intense: 211 people applied for the three places that were on offer. This led the EPSRC to increase the available funding and award seven Fellowships to people around the UK . Funding the RSE Fellowship may turn out to be revolutionary in the growth of Research Software Groups in the UK. (And it has certainly helped with coordination of RSE activities, because they simultaneously funded a network bid that provided the RSE Community’s first permanent staff member, Claire Wyatt.)

Another world first

This year, we wanted to do more than an AGM for our members, we wanted to run the world’s first RSE conference. Starting a new venture can be a little nerve-wracking. We knew that we could attract at least 70 RSEs to a meeting, but we planned to increase our numbers to 200 and our reach to be global. As it turned out, we had little to worry about.

Robert Haines took on the mantle of conference Chair, and he was joined by Alys Brett, Mike Croucher, Oliver Henrich, Catherine Jones, Gillian Sinclair, Christopher Woods, Claire Wyatt and myself.

Thanks to the network bid, we had seed funding for a venue. But booking a sufficiently large venue for a conference meant potentially blowing three years worth of seed funding—and I had to sign off on it. We announced the conference through the UKRSE Association mailing list, with plans to follow up with a broad publicity strategy to get people interested. This quickly became unnecessary, because our members syndicated the news through mailing lists and Twitter, and within a month we had more people waiting for registration than we could accommodate in the venue. This popularity brought sponsors, including Microsoft Research and Intel, which meant we could recover costs and charge a reasonable registration fee. RSEs have reported difficulties in finding travel money, so it was vital to keep registration costs as low as possible.

We received double the number of talks that we could host during the conference, so it was easy to line up an excellent schedule comprising technical discussions and presentations on the RSE Community. We also received more workshops that we could run, so we’ve been able to cover a wide range of expertise in these hands-on sessions. We will be hosting delegations from Canada, the Moore Foundation, and WSSSPE (which decided to co-locate with us), and we are receiving delegates from Norway, Germany, Denmark and New Zealand. As I write this, there are 15 places left at the conference. I doubt any will be available when this article is published, but there will definitely be another, bigger RSE conference next year.

A bright future for software—and for research

I’ve been involved in the Research Software Engineer campaign since its beginning, but I am constantly surprised at the popularity of every new activity we organise. I’d like to say that it’s down to the organisers, but it’s much more closely linked to the passion RSEs have for their work. They understand exactly how important software is to research, and they are keen to ensure that it is treated with the same care and respect as any other research tool. They understand that a sea change is coming in research and that they know that their skills will be at the vanguard of this change.

We’ve grown a strong RSE community in the UK, and this has helped us lead the world in recognising the importance of academic software developers. Earlier in this article, I discussed how some people thought the lack of recognition for academic software developers was too big a problem to solve. We’ve still got some way to go, but the speed at which we’ve progressed and the passion that has been invested in the campaign gives me the confidence to predict that it will be a handful of years before recruiting a Research Software Engineer for your research group is as commonplace as recruiting a postdoc.