How we work

Warning

This page is still in draft form and being discussed and developed. See the note on the parent page.

This page is mostly focused on how long-term scheduled projects, which are funded by the research groups themselves, work. Long-term tasks are scheduled by fraction of full-time-equivalent (FTE) over weeks or months.

For short-term code review tasks, come to any of our garage sessions and we will immediately take a look.

Types of service

  • Long-term service deals with jobs that last months, and are scheduled in terms of FTE percentage over months. This is often directly as salary from some grant, as a researcher would be.

  • Medium-term service deal with jobs scheduled in days. For simplicity, these are often fee-for-service paid internally from basic funding. Depending on your unit, they may also be free (paid by unit basic funding). This is not worked out yet - check back for details

  • Short-term could be a code review at one of our garages or a few hours of work. This is generally free (paid by unit basic funding).

Beginning

Check if it is a type of task that we can do: best to ask us (TODO: improve this description later)

To actually make a request for support, see Requesting RSE support.

Initial meeting

First, you can expect an quick initial meeting between the researchers and RSEs. Depending on the size and complexity of the project, there may be several to find the right RSE and ensure that we can do a good job helping you.

  • What scientific background knowledge is needed? How long does it take to get started?

  • What type of contribution will the RSE make (see next section)? For purposes of scientific integrity, consider if this reaches the point of scientific authorship (see bottom).

  • Researchers: provide access to code, documentation, and relevant scientific background in advance, so that they can be browsed. The more we know in advance, the better we can estimate the time required and how to best help you.

  • How do you manage your data? To map things out, consider this one-page data management plan table.

  • Final outputs, location, publication.

  • Time frame and schedule flexibility.

What we can accomplish

It is very important to consider what the practical outcome of the project will be, because different researchers have very different needs. Together, we will think about these questions:

  • What’s the object of focus

    • Software

    • Data

    • Workflows

  • What is accomplished?

    • Create a brand-new product based on scientific specification. Is this done in an agile way (continuous feedback) or is the exact result known?

    • Improve some existing workflow or software, possibly drastically.

    • Improve some other project, primarily maintained by someone else.

    • Prepare a project for publication, release, or being used by more people.

  • Future plan

    • Primarily teach via example, so that the researcher can fully continue developing the project themselves.

    • Provide a finished product, which won’t need updates later

    • Provide a product that will be continually maintained by specialists (RSEs or similar - us?).

Scheduling and planning

RSEs will be assigned based on discussion between the researchers, RSEs, and Aalto Scientific Computing (the RSE group). Your agreement is with the RSE group, so your RSEs may change (even though we’ll try to avoid this).

We can never promise specific results in a specific time: we always agree based on a certain amount of time. As you can expect, projects can sometimes take far longer than expected, so we try to budget plenty of buffer into projects to accomplish the mandatory tasks.

Our exact scheduling system is not yet decided: if you start now, you help design the system.

Costs and time tracking

TODO

Funding practicalities

TODO: This will be developed as we begin the program. See above for a description.

Getting started

Version control

One can hardly do development work without using a good version control system. Our first step will be help you start using a version control system, if you are not yet using one, or if you are ensure you are using it optimally. If you don’t have a preference, we’ll recommend git and GitHub / Aalto Gitlab.

Research background

If some understanding of the scientific background wasn’t important, you might be hiring a software developer instead. Expect us to take some time to understand the science.

Understanding existing code

Also expect that, if there is any existing code, it will take some time to understand for a new person. Also, there is likely to be a period of refactoring to improve the existing code, where it seems like not much is getting done. This is a necessary step in investing for the future.

During the project

Our RSE will most likely want to go work with you, in your physical location (well, after corona-time), a lot of the time. It would be good to arrange a desk area as close as possible to existing researchers. “Mobile-space” but close is better than fixed but further.

Our goal isn’t just to provide a service, but to teach your group how to work better yourselves after the project.

Software quality and testing

Software which is untested can hardly be considered scientific. We will work with you to set up a automatic testing framework and other good practices so that you can ensure software quality, even after the project. This also ensures faster and more accurate development in the future. We’ll teach you how to maintain this going forward. This is in proportion to the complexity of the project and need.

We also pay particular attention to the maintenance burden of software: you’ll be using software much longer than you write it. We aim for simple, reliable strategies rather than the fanciest things right now.

After the project

We don’t want to drop support right after the project (that’s why you work with us, not an external software developer). Still, we have finite resources and can’t fund work on one project from another, so can’t do everything for everyone. You can expect us to try to passively keep supporting you for during the “daily garage” time as best we can.

If your department or unit provides basic funding (see the implementation plan), then long-term service is included, and this has no limits. However, this is shared among everyone in your unit, and focused on strategically support that helps many people.

Tracking scientific benefits

We need to record the benefits of this service:

  • Researcher time saved

  • Computer time saved

  • Number of papers supported

  • Software released or contributed to

  • Open science outcomes (e.g. open software, data management)

  • New work made possible (e.g. grant or project wouldn’t have been possible)

  • Qualitative experience: increased satisfaction, educational outcomes, etc.

Releasing the software

A key goal of our support is releasing the software for broader use in the community (open science). Ideally, this will be a continual process (continue releasing as development goes forward), but we can prepare you for a first release later on, too.

We recognize the need to maintain a competitive advantage for your own work, but at the same time, if your work is not reproducible, it’s not science. We’ll work with you to find the right balance, but a common strategy is some core is open, while your actual analysis scripts which make use of that core are released with your articles.

Academic credit

Our RSEs do creative scientific work on your projects, which (depending on scope) can rise to the level of scientific authorship. This should be discussed early in the project.

  • The software-based scientific creativity can be different than what is published in your articles: in this case, it can make sense to release the software separately.

  • This is not to say that RSEs who work on a project should always be authors, but it should be considered at the start. See TENK guidelines on research integrity (authorship section).

  • A contributing that is significant enough to become scientific novelty and such that the programmer must take responsibility for the outcome of the work usually rises to the level of co-authorship.

  • It is OK to consider the code authorship as a separate output from the scientific ideas, and the RSE can help properly publish the code so that it is citeable separately from the paper.

See also

  • UCL RSE group processes: That page heavily inspired this page. Broadly, most of what you read there also applies to us.