> Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile.
Not that I agree with all the agile ideas, but if I remember correctly we had a process already which was supposed to start with "gather all requirements" and then the rest follows. It was called waterfall development and didn't work so great either, mostly due to the 'all' part in requirements being violated all the time in practice.
This is kind of precisely backwards. A survey is like a test; it asks 'will this work'?
A good civil engineer will do that as early as possible, rather than produce pages of engineering drawings blindly.
A good civil engineer will calculate the stresses and load factors on a bridge as soon as possible, rather than assume things will work.
A good architect will hand a sketch of a building to a client as early as possible, and ask 'do you like it'?
All of those are tests, and the engineering processes in those domains are put in place to ensure that that testing happens as early as possible, before mistakes are too costly to undo.
All the projects I've seen, even the ones where there are "minimum viable projects" have too much pressure from above (or have already been sold) so they aren't allowed to fail.
So I agree testing should happen as early as possible, but too often they're not real tests because failure isn't allowed.
Contrast that to software engineering, where beginning before you have requirements is seen as a requirement of being agile.