Agreed! There's waterfall & agile and dogmatic & pragmatic. I've never worked on a dogmatic waterfall project but have worked on several dogmatic agile projects (that made me strongly wish I wasn't).
In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion.
The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).
Hardware development is almost exclusively Pragmatic Waterfall. It's pretty much a requirement. Lots of reasons. Too many to list here (it would probably not be useful).
As a software dev for hardware companies, most of my life, I splashed in a lot of waterfalls.
One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the project) put extensive effort into the requirements phase. Working on the requirements and removing requirement conflicts (a very common thing), understanding of requirements, feasibility of requirements etc. etc., and, at the final stage, a week-long meeting with everyone (customer, companies) to work out the last kinks. Only after that did the next phase start: Creating software requirements from the system requirements, and from there, an architecture and so on. And, as this was something involving many companies in many countries and even continents, having everyone on the same page was essential. And it did work. Of course in the years following the project there would be bugs etc, but not fatal ones (which are typically caused by errors in the requirements- and architecture phases).
(We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive)
EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.
It works if your client knows and can articulate exactly what needs to be made.
I imagine that was more common in the 80s and early 90s when most people working in computer land were more tech savvy (relatively) than your average project manager today. And the market was less “get it out there asap” than it is today.
In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion.
The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).