Accident and Emergency of Research Software Engineering
Getting academic credit for impactful software
The topic of this year’s Software Sustainability Institute Collaborations Workshop is Software and Credit where luminaries from the Research Software Engineering world will get together and examine the problem of getting academic credit for the development of software. An example of the problem at hand is the story of Michael Double and BoneJ. Quoting from the SSI’s Software and Credit article:
Michael Double of the Royal Veterinary College, London (RVC) is the lead on the BoneJ project, his 2010 paper describing BoneJ is the mostly highly cited paper at the RVC gaining 2 new citations per week on average(!). However it was not deemed the right shape to submit to the UK Research Evaluation Framework committee by the RVC management even though they admitted it was highly impactful.
It’s a huge problem! Software is essential for modern research but developing it isn’t often recognised as a valid research output. If developers of highly impactful software such as BoneJ struggle, what hope is there for those of us who are rather lower in the research software food chain?
Embarrassing rash? The code doctor will see you now!
When I attend these annual collaboration workshops I find that my imposter syndrome, a feeling that’s always lurking under the surface of my psyche, starts to reach a kind of fever pitch. I feel like a country-bumpkin doctor who suddenly finds himself thrust into an advanced medical research conference. Surrounded by specialist developers of new drugs, surgical techniques and high-tech scanning machines, I’m just the guy who applies ointment to patient’s embarrassing rashes.
My path to Research Software Engineer has been via the IT support route where I’ve had many job titles throughout a career defined by restructure after painful restructure. Whatever my job title was, my role has always been the same — Researchers come to me with their code problems and I do my best to solve them (or convince them that they really want a different but equivalent problem solved).
These problems include things like:-
- My code is too slow! Like 10,000 times too slow. Can you help?
- My code sometimes explodes spectacularly, can you help? It’s 10,000 lines of VBA…..with some Fortran thrown in for luck.
- How do I get my code to run on the supercomputer? Why isn’t it faster when it’s finally on it? What’s Linux?
- Um…Our paper says the answer is 0.435 but the current version of our code, the one on Bob’s pendrive, says its 3.6 Billion. Can you help us reproduce our own results?
- How the hell do you do <insert task here> in <insert inappropriate technology here>
- People keep talking about code but all I’ve ever needed is this spreadsheet. How do I make my spreadsheet do <insert thing that REALLY needs to be done some other way>. I’m a Prof who’s best friends with your boss — your answer had better be spreadsheet-y!
- I can’t code, can you help?
- We’ve got code written in <old technology> but now we want it in <new technology>, can you help?
- We do our research in <insert expensively licensed software> and now need to run it 1000s of times simultaneously. This will cost more than the GDP of China. Can you help?
- Our research is based on this thing that’s a Fortran 77 kernel wrapped in MATLAB that’s been wrapped in Perl that we call from Python. It’s been in development for over 10 years and the computer it worked on has died. We are struggling to get it working on our new machine…can you help?
- We wrote some experimental code and it worked. REALLY well! We’ve now got lots of users and suggestions for improvements but have no process to deal with all of this. Can you help?
…and so it goes on. I work with researchers from almost every field of study and at every career stage — from Undergraduate project student through to professor and everything in between. The role is something like a mix of IT support, sysadmin, software developer, teacher, consultant, alpine guide and therapist.
It’s hard, dirty work and I love it!
Doing the job that’s put in front of you
Like many of my Research Software Engineer colleagues I have Opinions (capitalisation intended! They are strong but weakly held!) on the way things should ideally be done in research software development. These opinions have been formed from years of working in the trenches, observing the trouble people get themselves into and what’s required to get them out of it. They’ve also been informed by listening to the latest research on good practice from masters of the field.
Just as your local doctor might prescribe a healthy diet, exercise and cutting down on alcohol, I prescribe things such as version control, automation and making your code open. Despite knowing all of this advice, of course, many choose to ignore it for one reason or another and get themselves in a bit of a pickle.
One of the reasons I am so proud of the United Kingdom’s National Health Service is that no matter what you’ve done to yourself, no matter how rich or poor you are, no matter how much advice you’ve ignored, their fantastic doctors and nurses will fix you. Sure, they wish that the world was a better place and that people would take better care of themselves but, ultimately, they’ll do the job that’s put in front of them — not the one they wish they had!
I guess that when I do my job, I try to emulate this behaviour.
But where’s the impact?
You’ll not find my name on any research papers and I don’t have a big project such as BoneJ to stand behind. It is exceedingly difficult to demonstrate impact, in the accepted academic sense of the word, of roles like this but I am convinced that they are vital part of the research community.
One ‘solution’ would be to only offer my services to those who have already sipped from the Research Software Engineering Kool-Aid. Now that I have my RSE fellowship to stand behind, I could easily take this route and only focus on helping projects that smell a certain way…the right way. I could work on projects that have RSE time costed in from the beginning, using only the finest, freshest ingredients and released in ways that make it easy to demonstrate impact.
This route is very tempting! I could use only the technologies I love and work in an environment where my contributions were recognised at every level — funding bodies and promotion panels in particular. Thanks to the efforts of organisations such as the software sustainability institute, I believe that developers of quality projects such as BoneJ will eventually get the recognition they deserve. By focusing on such quality, high profile projects, my career would be assured!
To my mind, however, this is akin to the NHS only providing its services to rich, well-informed patients who take heed of all the good advice leaving the rest of us to suffer.
So…I’m probably not going to do that
The Accident and Emergency of Research Software Engineering
Over time, I have come to think of my particular style of work as the accident and emergency of Research Software Engineering. It’s usually unglamorous work with little hope of formal recognition and the threat of cuts (or being reassigned to printer support!) hangs over your head every day. As anyone who’s desperately needed their services at 3am can attest, however, an A+E department is exceedingly impactful!
Despite the success of the Research Software Engineering idea, I believe that the need for the A+E type of work will increase over time along along with the percentage of researchers who need to write at least a little code. This tweet from Southampton University’s Ian Hawke, quoting Software Carpentry’s Greg Wilson, summarises my thoughts on this matter perfectly.
Here we go with @gvwilson : the gulf between the computing scientific “elite” and those emailing spreadsheets is growing, and that’s bad.
— Ian Hawke (@IanHawke) November 10, 2015
This observation closely matches my own experiences from the front-line of RSE support. Part of the role of practitioners such as me is to help close that gap by raising the game of those who email spreadsheets. I feel that I’m making progress in this area although I often wish I had more staff!
Another part of the role is to figure out how to get credit and demonstrate impact for this kind of work or we’ll risk losing it in the next round of cuts. I’m struggling with that aspect to be honest!
If you feel that your work has elements of an Accident + Emergency Research Software Engineer in it, feel free to speak up in the comments.