| If folks remember, one of the seminal Waterfall documents was actually a "Don't do it this way." document[0]. That said, sometimes, Waterfall is the best way to do some projects, but I'd say very, very few. It does work reasonably well for hardware production. Many hardware companies apply Waterfall to software, because it's the process they know. TDD is also a technique that can encourage a "waterfallish" approach, as the design needs to be fairly complete, right at the beginning (to be fair, it is possible to do TDD iteratively, but that takes effort, and many shops like to reduce effort as much as possible). I tend to keep my designs as fluid as possible, refining in a JIT manner[1], and prefer using test harnesses to fixed unit tests[2]. I personally have a beef with the way many shops handle the concept of MVP. I feel that a significant number of shops use it as an excuse to shove out a hastily-built lashup; favoring adding features to ensuring quality. I have come to believe in the concept and purpose of MVP, but I am also one of those "grizzled, cranky oldtimers" that has seen many, many prototypes become the "heart" of applications, and even infrastructures. I won't mention some rather obvious examples. I feel that it's important to ensure quality from the first line of code, and to accept the fact that the MVP will become the core of the system. [0] https://en.wikipedia.org/wiki/Waterfall_model#History (Look at Royce's presentation) [1] https://medium.com/chrismarshallny/evolutionary-design-speci... [2] https://medium.com/chrismarshallny/testing-harness-vs-unit-4... |