What to expect when working with ARC’s research consultancy service
Collaborating research groups need to understand and agree our ways of working as set out below. These supplement UCL’s general commitments on staff interactions for maintaining a healthy working environment, as set out in the Dignity at Work Statement. Project leads will be asked to confirm their agreement in writing before we commit to a collaboration.
Part of ARC’s mission is to propagate best practices for software development and data science within research. We therefore aim to model these in our interactions with researchers and mentor teams in their application. What this means in practice is set out in the sections below. The primary starting point is that we use “agile methods” for project management – while these originated within industry in essence they involve applying a research mindset to the technology aspects of projects, recognising that the end point is not fully known when a project commences, that cycles of experimentation and refinement of ideas are typical, and that through reflection we regularly refine how we work. Effective management is essential to delivering on the goals and deadlines of the project.
There will therefore be regular (e.g. fortnightly) meetings organised between ARC staff and the project leads, for the purpose of demonstrating the work done during the preceding period and agreeing priorities until the next meeting. These will be arranged at times mutually convenient for all involved.
This is however the minimum required level of interaction! We favour rich collaborations, and so in-depth discussion meetings and other means of communication (e.g. project Slack channel, GitHub issues) are encouraged for efficient exchange of information.
The staff working on the project will be chosen by ARC, based on skillset and time availability. Our preference is for at least two research technology professionals (RTPs) per collaboration, for the benefit of robustness in the event of changes in the group, and to facilitate sharing of knowledge. We also reserve the right to change staff throughout the project (although will endeavour to do so in a way which is mutually beneficial, recognising the potential cost of bringing a new person up to speed). The research group has the option to have the RTPs working at their premises for a portion of the allocated time; indeed we encourage this where possible to strengthen the collaboration. Note however that staff remain managed within ARC and are not seconded to your group, unlike postdocs.
ARC supports many research projects across UCL and beyond simultaneously, and needs to manage the time commitments individual RTPs give to each project in order to ensure each one is successful, as far as it is within our power to do so. We are often under very high demand and hence need to schedule work several months in advance. While we strive to adapt to changes in research priorities and unexpected deadlines, we cannot guarantee being able to do so. In particular, if there is a lack of responsiveness from research groups during the scheduled work period, the project may need to be rescheduled resulting in significant delays. Similarly, if extra funding is found near the end of a project, we may not be able to extend it straight away and instead need to pause activity or change staffing. The collaboration will be most effective if we are informed of known deadlines well in advance, and schedule tasks together with you in order to meet these. We will update you on the forecast schedule at the regular meetings as desired and will let you know of any material changes on our side as early as we can.
ARC costs for work on either a pay-scale or day-rate basis. Note that we do not commit to produce specific deliverables for a given price, in the way that industrial IT contractors typically work. Instead we commit to a given number of hours worked on the project. These costs assume 100% FTE includes appropriate allowances for meetings, holidays, training, and sick leave.
We use tools for tracking the time spent in projects and are willing to give updates on this at catch-up meetings and when requested.
Estimating the duration of tasks accurately on research projects is by nature difficult. Where tasks take longer than anticipated, we will notify researchers as early as possible and discuss how to prioritise the remaining work. If, on the other hand, work progresses unexpectedly quickly, we can work on additional tasks up to the time agreed.
ARC staff will always endeavour to understand the codes with which we work; we do not believe effective research software can be constructed without an understanding of the code’s purpose. Researchers will commit to giving the team time to read up on the field, and will supply appropriate literature to the team, when necessary.
Similarly where new specialist technical skills are needed, training time will be included within the project. Training in general technical skills is not charged to projects.
All projects must use version control and an issue tracker with good task management features. Researchers agree to learn and use GitHub where they’re not using something else already. Researchers agree to review issues on the issue tracker, which is where development tasks will be recorded and prioritised, and review code on pull requests or otherwise provide feedback, in a timely fashion.
Refactoring is important to ARC.
Researchers are asked to understand that developing code which is sustainable is one of the main purposes of ARC. You might see several development cycles go by with no apparent feature work while we work on the software structure. This will lead to more robust, reliable code and faster progress later.
We will always work to a software quality assurance standard based on continuous automated testing, with tests for new features typically being written before the implementation (akin to forming a hypothesis then doing the experiment in the scientific method). Therefore, researchers may see time pass while we are working on establishing the test scaffold and framework for the code, again without apparent feature work. We also expect to be given realistic test data to design meaningful tests and take rare situations into consideration.
We will provide training and mentoring for the research team in using the test framework created and ensuring their code quality remains high after our engagement. Researchers will agree to engage with this process and try to keep up a testing approach, committing to fix broken tests in a reasonable time.
After the end of the project, small support requests will be taken care of by the RTPs for a finite time (twice the project duration) on a best effort basis only. If desired, and allowed by funder rules, some staff time can be held back for longer-term maintenance at a pre-agreed level.
ARC is a strong proponent of UCL’s Open Science and Scholarship policy, and we make all our work as open as possible. One of our aims is to raise the profile of non-publication research outputs within the wider research community. We do not require that we are named as authors on your research papers (though we’re happy to help in this way too if desired!), but we are keen to co-author software papers with you, publish releases of software and data which can be given a DOI and cited, promote the tools and methods created at relevant conferences, and generally disseminate the work we do as widely as possible. Such activities also help to enhance both of our track records for subsequent grant proposals. We expect suitable time to be set aside on projects for these activities.