7 ms·
There seems to be an underlying tone of waterfall=bad. That’s missing the nuance of why it’s often considered bad. Usually because you never know the requireme
by Too 3y ago
There seems to be an underlying tone of waterfall=bad.
That’s missing the nuance of why it’s often considered bad. Usually because you never know the requirements up front, leading you to build the wrong thing.
Except, when doing a rewrite you do know the requirements up front. Based on the experience of your current system.
- crazygringo 3y agoNo, that's only half of why waterfall is often considered bad. The other half is because of the unpredictabilities in building software period -- internal rather than external. You can build out one component fully and another component fully and then finally test them together at the end and discover there's a horrific race condition that requires rebuilding both from scratch to fix. That's why a more iterative process is considered best practice today, to find showstopper bugs earlier rather than later, particularly to catch and address architectural issues sooner rather than later. (But also, like I said, rewrites are rarely trying to produce a 1:1 copy in the real world. The whole point is usually to fix a bunch of problems with the previous system along the way, not to continue to reproduce the unwanted behavior. I'm not saying there are never perfect 1:1 rewrites that intend to reproduce all the bugs and warts and all, but it's rare.)