All right. So this is probably two one hour talks shot in 30 minutes.

So I hope everybody's caffeinated because we're going to go fast.

Okay. So I want to talk a little bit about software development

and Rubin because that was the placeholder title that I was given.

So I need to satisfy the customer here.

But I also want to take a little bit of time towards the end

to talk about deployment automation because partly because this is the thing

that we're doing right now. So it's fresh in my brain.

But also because I think it's something that we're doing that a lot of folks may not be familiar with.

So I just want to see your mind that this is a thing

and hopefully encourage you to ask me questions or look a little bit further.

All right. So first we have had to rename for those of you who have been around for a while.

We used to be LSSD as a project. The Large Synoptic Survey Telescope.

We're now the RRC Rubin Observatory.

But in a brilliant attempt not to have to rename all the code repositories,

we have taken LSSD and we have named the survey after it.

It's the legacy survey of space and time.

And we also have named our telescope, which is a system on the survey telescope

recognition of this generous contribution to the project.

I still haven't quite trained my brain not to make any mistakes here.

So please pardon any inconsistencies.

Like to tell you a little bit about who we are.

So there are basically three, you know, we're just talking about software here.

This is great. So there are basically three subsystems at Rubin

that actually are producing significant quantities of software.

That's data management, telescope and site, which are the people who are interfacing

primarily with the hardware and instrument, and education and public outreach,

who is building tools for general public and school use.

Data management has about 107 humans in it, adding to about 68 FTEs.

And we're very distributed, which actually has been very good in the time of COVID

because we have fairly good communication and collaboration structures,

which has helped a lot.

And I lead one of the teams in data management,

which is a science quality and related build engineering team.

I'm also the project manager for the Rubin Science Platform,

but that's a whole different talk.

And that's my wonderful team in front of the commissioning camera.

So, all right.

So I want to talk a little bit about software development, and we don't have time.

So you're going to get the tweet length version of things that I really want to bring out.

We've been doing this now for five years,

and I kind of feel like I know what has worked and what hasn't.

So I want to talk a little bit about the things that I think

ultimately have made a key difference in the quality of life and our quality of our software.

And this is my personal view, and I'm opinionated.

So you ask somebody else at Rubin, you might get a slightly different story.

But I think there will be a lot of consensus on these actually.

So lesson number one is stop writing software, like stop.

We have a terrible tendency in this field to start writing software first

and then wonder if anybody else has done it later.