History of Aalto RSE

The term “Research Software Engineer” was first heard around by us around 2018 as part of the CodeRefinery project. At first, the hearer didn’t understand what it was, but by 2019 it was clear, and clear that we needed something like this.

Why did we need this? Because it’s what we were already doing, and what our researchers. By connecting to an existing concept, we would be able to make our work more professional. But what was “research software engineer” to us? We took a very inclusive view: someone that was somewhere between the technology of research, and the research itself. By this view, we were all already RSEs (although most of us focused more on basic infrastructure than close scientific support). Still, the idea that we could focus more on direct researcher needs was very interesting to us.

Initial motivation

What would a new “research software engineer” team allow us to do? The basic idea was “more of what we were doing”, but we needed to justify more.

Saving time. A story from some of our research past: Once, one of us was helping someone with preprocessing some data. We took a few days of our own time to import the data into a sqlite3 database, and an hour per day over the next week to teach them how to query it with SQL (going back and forth and adjusting the database to their needs). They soon caught on and a few weeks later came back with the comment: “if someone had helped me with this when I started my PhD, I could have saved three months of time by now”. As a organized team, we could easily make a case of saving far more time than we are using.

More equitable research. Sure, some researchers are fortunate enough to have the background and time to learn everything, but modern universities are diverse and interdisciplinary. Without good computational support structures (which modern academics don’t have time to do themselves, with all the demands placed on them), plenty of people get left behind.

Our management cared about the above, so was supportive of our project.

Better research practices. We can make research more reproducible, shareable, and open. To be honest, this is a hard sell, since it sounds like something that should be solved by the academics themselves: if they need X they can hire for X. (Since we are hosted under an academic school, not a service unit, you could argue that we are academics hiring for X).

One criticism that came up was that “academics know how to do things themselves”. Our later experiences clearly have shown that with a big enough audience, plenty of people desperately needing help in everything we offer. Modern science is too complex for anyone to know everything.

Initial years

We started with basic funding for two full-time staff: 50% funded by the School of Science and 50% funded by three departments within the School of Science. The staff would focus on these units while working to find project funding.

Our initial work came from HPC cluster users (and this continues to be a big customer segment). By looking at our existing issues, we could find plenty of researchers who needed more help than we could provide with our basic cluster support. We could also identify users who had inefficient workflows or other usage problems and direct them to the RSE support. This easily gave us plenty of work.

Example range of projects we do: we aren’t just “software” but many things. We don’t just do long term projects but plenty of short-term support too. We sometimes do things outside of this table.

Over time (months), we could continue to find people through our existing support channels, and also drop-ins who specifically came for RSE support (still, many of these were cluster users) from our funding units. Very many RSE projects came from someone who arrived asking about some seeming-simple research task, but it turns out to properly accomplish their goal there’s actually a lot of development or debugging that needs doing. We can do that for them, so they can focus on what they need.

Our long-term funding goal was to receive a significant amount of funding from projects (as in: from external grants). Some initial projects were willing to fund us, but the finance practicalities were too complex (too much effort to internally transfer the money) and this didn’t happen as soon as we wanted. Our school and departments were happy to have us support research while waiting for the funding to be sorted out.

We never had any shortage of work to do: with a minimal amount of advertisement, we had a steady stream of projects that was neither too much nor too little.

Steady state (2022-)

Projects continued to come in about as fast as we could do them: no advertising needed, also the delay to starting a project wasn’t that long.

We got some big projects funders: some flagship projects funded full-time 100% RSEs as part of our team. They would be dedicated to that project, but in practice our whole team is working together on whatever projects there may be. This model seemed to work pretty well.

We did work out a sustainable project funding method: the general agreement was that projects taking less than a month would be funded under basic funding, while projects would be expected to fund work lasting more than a month themselves. This was the right balance of “project funding” and “minimize administrative overhead” while giving the best benefit. Yes, this was a significant investment into research quality. With this system, several projects began providing us with funding.

We also received funding from our university’s IT Services. They often had support requests which went beyond IT support into “research software engineer” support, and thus began providing funding projects outside the School of Science. This eventually became an established funding source.

When you consider funding from stuff dedicated 100% to projects, smaller project funding, and IT Services funding, we certainly have most of our funding coming from project sources.

All during this time, we never had a shortage of projects. More and more projects came specifically as RSE projects, and not as cluster usage help requests. We maintained a nice self-emerging balance, where our projects were in balance with the time available without us having to do any advertisement. (On the other hand, this mean we probably weren’t reaching the people who most needed us, so this isn’t exactly a good thing).

Future (As of 2024)

We clearly have more projects than we can manage, and the scheduling delay is becoming longer and longer. This is even as our effective team size and funding has increased. Our projects come from a wider variety of schools, and lots of time is spent on basic issues.

We’re thinking of the largest team size that makes sense, both from keeping it managed and fitting in with the academic system.

We’ll need to think about how to scale to and support work from more schools at Aalto. Funding should come from more diverse sources, and we should try to support projects and researchers earlier, rather than getting projects after they are started and need revisions.