Know what the research questions are

[zzcgujl]

The software is being developed for research purposes this means that the requirments are strongly linked to the research questions. You need to know what are the short term, mid term and long term research questions that this software will attempt to answer.

[gvwilson]

Agreed, but:

1. How do you figure that out if you're not the PI (and possibly not an expert in the particular research domain)?
2. How do you deal with the fact that "requirements" emerge as results come in? Or do we assume that this course is about building digital scientific instruments, i.e., we focus on construction of libraries and applications, rather than exploratory work?

[zzcgujl]

The requirments specificiation for software is there to legally define the relationship between the developers and the consumers of their work who will pay the developers. Academic research is funded as projects where the funding is paid up front so the needs for requirements specification is not there. Many groups and people I know in research computing (I interviewed about this a few years ago) never bother with requirements spec because it is not useful. More generally I am assured where there are small groups of developers who have a long term relationship with the organisation they are paid by requirements do not work there either - commercial or academic. This way of working is exceptionally efficient. This is the basis of agile methodologies. I believe that research computing when done well follows a lean methodology i.e., the "requirements" emerge.

If you are someone who needs to figure out what is going on then you communicate with the others to find out. This is part of the getting to know the team step and it facilitates you to become part of a long term collaboration which I just mentioned as being important.

I would not recommend that someone who knows nothing about accounting writes accounting software - and I would really not recommend it to someone who is not interested in accounting. I am not sure why this person does not know about the particular research domain - a student should want to learn; a post doc applied for the post so should have an interest, a research software support expert picked the career because they like working in diverse research domains. If anyone else is being forced to write the software then you have recruitment and administrative problems.

[gvwilson]

I agree that agile is a better fit for small research projects because
of the emergent requirements - I've certainly never had anything that
looks like formal (contractually enforceable) requirements when working
in academia. Any good guides to agile requirement elicitation? "Ask
the PI" has a long history of not working out well.

[zzcgujl]

I imagine that you may be getting caught in the idea that there is a ideal answer but when you think about any ideal answer the reality is not complex and it does not work. There is little recorded work on what the research computing method is - I read a great thing on it a few years ago I will see if I can dig it out.

Also I am not sure why the PI is so important to this discussion. One of our research councils is thinking of removing PIs and CoIs. The important think that you need to do when you are in a research software engineering team is have a team that is committed to a positive outcome, anyone who is committed to a positive outcome will spend time and help with a new member to the team. This could anyone in the team - students, researchers, the PI, CoI or people external the Dean or the head of school. You should aim to talk to whoever looks useful and is willing to help.

I think the best information on this will not be in the software engineering arena but in the management literature because those guys have really studied teams and how they work. Recently I worked in a team where towards the end of the project everything just seemed wrong. I used the management literature to analyse the team and the team meetings. It was through that I realized that the 2 members of the more extended team benefited from the projected failing and that they were buddying up to make the project less effective. Their careers have blossomed .

I think research computing is lean rather than agile. I used to think that lean and agile are the same thing but by talking to a number of freelancers I have come to realize that they are not. While some more established and better funded research computing teams may be more agile than lean I think most are lean. Some methodologies from agile can be used in research computing - coding dojos, paired programming sessions, hackathons for skill improvement and improving communication within the team but not the full methodology.

Lean is much more about having a good understanding of the market so that you can adapt quickly to changes in the market or take advantage of gaps that you notice. It is also about making sure that each bit of effort that each person contributes can be used in as many ways as possible to achieve your (and the teams) long term success. I think it is the lean nature of research computing that makes the development of tests and documentation relatively un-important. You need to have an established user base to make either really worth while and developing things that you do not need immediately just does not work in the lean method.