What brother's me about this comment is the implicit assumption that waterfall is a universal bad and things that are less waterfall more agile are good/better.

What brother's me about this comment is the implicit assumption that waterfall is a universal bad and things that are less waterfall more agile are good/better. This is incredibly false. Agile (or non-waterfall) style development is useful in specific limited cases. Where you're creating something where the cost of failure discovery is small. You're writing a mobile app, or a b2b website, or some other common problem. It's cheap and easy, and the cost of a failure is so small that it's cheaper to just fail and go from there, then to spend anytime thinking about how something may fail. If you're doing something mission critical, space shuttle, something involving expensive parts, something high risk, you make sure you do thorough requirements analysis, well specified behavior, and well defined failure modes. You break the system down into individual small components (the more critical the failure the smaller the components) create well defined specifications for each component, test the he'll out of each one indicidually, ensure they work to spec and then combine them. You don't Agile your way through it. Agile, you'd just get something minimal working end to end and iterate. If the thing you're working on can explode you don't just iterate through a minimal user story. You define each item well and ensure it meets it's specs and you understand it's failure modes. Same thing for the topic at had on impact of technology. Understand the failure modes of the components you're creating - and write them in your paper.