Introduction

Dozens of books and thousands of tutorials describe how to manage mainstream commercial software projects, but research software is different in several important ways:

1. Contributors are usually users, and volunteers rather than employees.
2. Project life cycles are tied to grant cycles.
3. The definition of "done" is shaped by publication rather than revenue.

This workshop introduces the ideas and tools you need to manage a team of up to a dozen people working together to build research software. It draws ideas from commercial product development, and focuses on what you need to know when you are responsible for the output of other people rather than for building code yourself.

Learner Persona

Jess, 31, completed a PhD in ecology three years ago and now works for a national lab. The data cleanup and simulation software she wrote in grad school is being used by two dozen research groups around the world, several of which have started contributing fixes and extensions of varying quality. Jess has just been given a post-doc and a junior programmer, and needs to decide which pull requests are safe to merge, what everyone should work on next, and how to handle people who spend more time arguing in group chat than writing code. This workshop will show her what a healthy mid-sized project looks like and how to manage both staff and external contributors.

Structure

Each lesson includes a brief before-and-after description to help you understand how it's supposed to help. The exercises are designed to give you something concrete to take back to your own project. It's possible to do them on your own, but they are much more rewarding when you can compare your ideas with a partner's.

Some exercises ask you to interact with LLMs. We recognize that many people have concerns about these tools, and that they are still so new that nobody's really sure how to use them. We are therefore especially grateful for feedback on these parts of the lessons.