> than train users and customers to frontload requirements in order to benefit from the design decisions

No matter how much training we give customers, the very best they can do is give us the reasonably foreseeable requirements. That was maybe possible for a couple of decades when our main job as an industry was to take well-evolved paper processes and put them on a computer. Even then, though, people were getting better results by shipping every few days in response to observing actual user experience.

I don't think trying to frontload requirements works anymore, though. Startups are effectively machines for learning. We can't predict what learning will happen; if we could, we wouldn't be learning. And those startups are creating change for everybody else, making it impossible to know what competitive challenges might arise tomorrow.

So I think it's time for us to stop pretending we can get everybody else to freeze the world just because it's more convenient for a particular set of design techniques.

> 25 years later, we know the truth about how easy it is to shoehorn in 11th-hour feature requests when using object-oriented code.

I was a NeXT programmer back then. 25 years later, it is much easier to add feature requests to OO codebases. The three big differences: automated testing is common and easy; refactoring a design is a well-understood process; and you can deploy to millions of people with zero additional cost or work beyond committing and pushing to master. Which in turn means that the whole notion of "11th hour" is dissolving. Which hour is the 11th if you're releasing a few times per day?