Sure, waterfall might work for very small fixed contexts. Control software for a spacecraft is a great example. I can sit down now and start designing software to do physical calculations for a system that won't ship for 7+ years, confident the laws of physics won't change in that time. In fact, NASA did this in the Apollo program.

Most software is used by customers with changing needs and competitive pulls. I've built software in the last 2 years that we would have taken a radically different approach to if LLMs were available, because they're great at summarising natural language. But they weren't. Imagine if we'd been building something for 2 years and never learned anything about changing technology or customer expectations - instead we shipped something fast, and then looked back after we learned about new things and made it better. That's how the World should work, and why software is not like building a bridge or a house or basically anything else in the history of engineering.

As to your specific exampleS: I have some detailed knowledge of hospital EHR systems, and they are so massively, hilariously broken in ways that modern software practices could easily help address. I suggest reading Accelerate [1] for data and examples of how agile applied to DevOps practice in particular means you can be more responsive and produce safer software, especially in that context.

I, like you, also prefer software for stuff that matters. I've been trained in formal methods, I've done embedded systems development, I've worked in medical/healthcare contexts. Your statement that what I've written above does not apply to those environments (including the use of formal verification methods), doesn't make sense to me.

[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...

Accelerate https://www.amazon.com/Accelerate-Software-Performing-Techno...

Team Topologies https://www.amazon.com/Team-Topologies-Organizing-Business-T...

Making Work Visible https://www.amazon.com/Making-Work-Visible-Exposing-Optimize...

> Frosgren seems like a newb

She co-authored Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Techno... . She is also currently at Microsoft Research and was previously at Google and GitHub. This may be a hot take you disagree with, but she's no newbie.

I took her point to be "make sure anything you build is a lot better than anything you can buy, because there are a lot of unexpected expenses in building".

> we need to figure out another way of working that isn’t agile,

Isn't devops the next generation? (I mean devops as promulgated by Accelerate: https://www.amazon.com/Accelerate-Software-Performing-Techno... , not 'smoosh the devs and ops teams together, add Jenkins and hope for the best'.)

And you'd be wrong.

First, I am not aware of any operating systems that are developed using agile methods, and second the empirical evidence is in that agile improves quality, so it would be better if they were.

https://www.amazon.com/Accelerate-Software-Performing-Techno...

Yes, we're in agreement. A coworker of mine pointed me to the book Accelerate [1], which I admittedly still haven't read, which also mentions that organizations where management tries to make sure engineers are at 100% utilization end up being dysfunctional, partly for the reasons you pointed out.

[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...

I prefer studies over anecdotes and found this: https://www.amazon.com/Accelerate-Software-Performing-Techno...

According to this study, you can measure a team's progress and ability with:

* number of production deployments per day (want higher numbers)

* average time to convert a request into a deployed solution (want lower numbers)

* average time to restore broken service (want lower numbers)

* average number of bugfixes per deployment (want lower numbers)

I am curious about other studies in this area and if there is overlapping or conflicting information.

So...shouldn't the focus be fixing the fact that release cycles take several weeks?

This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

https://www.amazon.com/Accelerate-Software-Performing-Techno...