> In Waterfall, the design and requirements are "one and done." They are not supposed to be revisited and iterated.
The article doesn't seem to be about waterfall though? But even if it were, I don't see what's novel here. In waterfall, the design and requirements are "one and done" for version 1.0. But then you plan a version 2.0 in response to the new features desired, and then 3.0, and so forth. In any case, the article doesn't even mention waterfall or agile, so I don't think it's about that.
The article isn't really about any particular model. It's about product development, in general.
> ...But then you plan a version...
Yeah, but these are painful. I know of which I speak, as I worked for decades in Waterfall companies.
Rapid iteration at High Quality is really difficult, but it's also the only way that I've found, that delivers truly useful software (the products that I write). It's a great deal more difficult to do this with hardware, though.
I worked for hardware companies, for most of my career, and suffered hardware development methodologies forced upon software. It was painful.
Since working on my own, I have developed what I call "Evolutionary Design" techniques, and they seem to be working, but I also work at a much more humble scale, than I used to.
Sure, I totally agree with you. That's why waterfall gets a bad name. It just seems like waterfall vs. agile is a totally separate topic from the article.
But the prevalence of Waterfall is the elephant in the room, that interferes with rapid iteration, which is what the article is about.
We can ignore it, if we like, but it's still there, making big giant ploppers on the coffee table.