Addendum: Seven-Figure Scientific Software Projects

2024 August 8

There’s at least one important point that I forgot to make in yesterday's post.

I wrote that while software projects are in many ways like hardware projects, one noteworthy difference is that they’re basically made entirely out of people. While an established hardware development program is supported by durable physical assets like lab equipment, an established software development program is, to a very good approximation, completely intangible. This makes it extra-important to provide stable, sustainable support for the people involved. Of course, this is not to imply that such stability isn’t important for hardware programs too, or that people who build hardware are interchangeable.

What I forgot to point out is that this is also the case for core astronomical research itself! Most established research programs in exoplanets, gamma-ray bursts, or whatever, are likewise made entirely out of people. I’m quite sure that folks with more equipment-intensive programs, like lab astrophysicists, would agree that what they’ve built is mostly about human expertise, rather than the hardware.

And universities have a time-honored mechanism for recruiting and retaining the experts around whom these research programs are centered. You hire them and you give them tenure. It’s a decently successful approach.

This is really the thing that’s been bothering me. It is indeed very difficult to recruit and retain the skilled professionals needed to build high-quality software in a university context. But we already have the systems in place to do this! We just need to collectively decide that software leads deserve tenure-track slots.

Now it remains true that building astronomical software, like building hardware, is not quite the same thing as doing astronomical research itself. The act of writing software can (ideally) create tools that lead to new astronomical knowledge; and, something that’s pretty underrated, it can help capture and make explicit existing or previously-vague astronomical knowledge. But it doesn’t create new astronomical knowledge per se. Furthermore, I’m particularly interested in infrastructural software, which you could view as being an extra step removed from knowledge creation: tools that help you create more tools.

And my impression — maybe it’s wrong — is that at the moment, to get hired onto the tenure track as a tool-builder of either the software or hardware variety, you need to have a story about how you’re going to bring in a lot of money to support your activities. A plan to operate in artisan craftsmanship mode, just you and an apprentice in the basement, won’t get you hired. Hence my focus on grantmaking in the previous post.

The other analogy to mention is that the commonplace uncertainty and unpredictability of the software design process is also very reminiscent of the uncertainty and unpredictability of scientific research itself. You try stuff; you realize that your first plan wasn’t working; you pivot; something surprising catches on with your colleagues. So in this way too, software development should be a very comfortable fit for academia. Innovative hardware development has the same features too, but for understandable reasons the speed at which things in software can evolve feels a lot closer to the speed at which the science itself can move.

All of this makes me optimistic that there’s a way to find a home for innovative scientific software development — and developers — in the university system. But it would certainly be a lot easier to do so if we had more well-established avenues for PIs to get funding for substantial software projects.