They Knew Waterfall Didn't Work

Also he stated later (probably not in the paper) that a waterfall based project never should be longer than 2 months in scope

I am 60 and have been doing software development for about 30 years. The waterfall method was a staple in college back then. Also flow charts, they loved flow charts. Had to have a flow chart for every program you wrote. I might create a flow chart, once a year, to help think there a solution, but that is about it.

what i find very interesting about this all is that: when i am doing my own code for my own personal projects, i often do not even know exactly what i want until i start writing code and interacting with it, and trying to plan out everything that i want would be extremely time-consuming in of itself and not very useful for me because my requirements i want for my own personal projects are always constantly changing. i pretty much mostly just write code that i think will be useful for me later as i am thinking about how i could potentially use it, and, for the most part, that has worked out very well for me. the thing about this, though, is that we are all constantly changing. not only do we all have different goals, but even our own goals can vary and be different from what they were like before. and this will also be especially true with your customers as well who often do not have a full understanding of your practice or what they want either. and that inherently on its own would make a process like this more difficult if you're not allowed to iterate or expand upon the original idea. oftentimes, people dont even realize that they want something more specific until they see that it is missing.

I would like to thank Christopher, He helped me pass software design patterns back in 2019. God bless you brother 🙏

Just wanted to say hi Christopher, and thank you for coming back to YouTube. I've rnjoyed your series on design patterns, and it was the very first time after 10 years of coding that they made sense to me. You even inspired me to start my own YouTube channel, by sharing your knowledge. Glad you are back, looking forward to more great concepts explained here! Great job

I subscribed your channel a long ago but didn't realize you weren't posting anymore. Glad you are back again. Your content is very valuable!

Everything depends on the volatility of requirements. If you have clearly defined and static requirements with a large team, waterfall is a viable option. But when requirements are volatile, which many business requirements are, then waterfall becomes extremely inefficient and risky. But the solution isn’t to skip different stages, instead it is to cycle through the entire development pipeline of waterfall more quickly by horizontally slicing the requirements so that you can get user feedback early and frequently against uncertain and volatile requirements. This minimizes the risk and inefficiency of process but this also comes with drawbacks of lack of overarching architecture

Ohne of the main problems is that you will never have precise specifications in requirements. If you have uncertain components in the beginning of the chain it can not hold until the end ...

So glad you're back Christopher!

Agile: the manifesto (predated by Crystal Method) vs Agile: the scrum compromise that ruined software Now that's a battle I'd like to see!

Great video! Some notes that might be of interest: Waterfall was introduced in an earlier paper, by Benington, in 1956. It was based on a methodology developed in the SAGE project. So, when Dr. Royce wrote his paper in 1970, Waterfall had already been failing and floundering for fourteen years. Benington later, in 1983, criticized Waterfall, and wrote that an iterative approached could have halved the cost in the SAGE project. Criticisms of Waterfall were usually done exclusively from a risk perspective until 2003, when Tom and Mary Poppendieck applied queueing theory to software process design, and showed that the massive batch transfers in Waterfall projects lead to delays and cost overruns, even if everything works out as planned. That is, Waterfall is a disaster even when it works as intended, which it rarely does. In 2009, Reinertsen used queueing theory and cost of delay for a more detailed analysis in his book Flow. Worth mentioning that Waterfall had so disastrous results that the US Department of Defense prohibited defense contractors from using it in 1994. ...and now, we have people who want to revive it. Sigh!

In my 25 year experience(hard sciences) I never once saw someone that knew their requirements. They only knew what they wanted and more often than not had to be told what data they should base their requirements on. I am so happy that this is public now! EDIT: I am a simple man, I subscribed.

I think there is often one aspect missing from these "waterfall is stupid, agile is obviously The One True Solution" -types of pieces. It was a different time back then. You couldn't just send out updates, bugfixes, new versions, etc. because there was no such thing as the Internet. Once you shipped the product, it was Shipped. Also, another issue I rarely see mentioned is the fact that many customers simply do not have the time, resources, knowledge or interest to be part of the development lifecycle. They simply have a spec, and they want something that fulfills it. Of course, after it is fulfilled, they might have opinions about it and want things done differently - which is kind of exactly the "do the whole thing twice"-routine discussed in the video...

Hmmm. . . interesting discussion. The first thing is you have to have good people throughout the process doing their work. If you have that, then you don't have to go back. If you have lousy people, who are not thorough, then you get sloppy work. Things are missed. Then you have problems. The other thing is that the cost to fix problems goes up 10 times at each step. Early in the design process, it is cheap to fix mistakes, missed concepts, or hidden issues. However, if later on in the release cycle QA testing finds problems, then it is far more expensive to address. It means the code has to be fixed or maybe a redesign is necessary. Then the code has to be retested. And God forbid that problems are found after the code is released to production. It means the previous code has to be redeployed and so on. Customers might be involved. It is truly a serious and embarrassing situation. And it is immensely expensive all the way around. People lose their jobs when code has to be backed out from production. The bottom line is that you have to have good people doing good work.

I didn't know this paper existed so this was super cool to hear. Curious on what you think about something. Iterative style approaches seem to be the same as waterfall but with much tighter feedback and implementation loops as well as being cyclical. Would you agree? But it's not like at the end of waterfall when business requirements change or a new feature needs to be implemented that you completely scrap the project and rebuild it with the new feature, you would be iterating on what you built. To me it seems the difference in a lot of ways is how much effort and complexity is implemented into the initial design and scope. I guess an analogy I would think of it agile/iterative development is akin to walking 10 yards in 1 direction, then looking back and asking the customer/stakeholders if this seems like the correct direction to walk. Waterfall is like walking 2 miles in 1 direction and then asking for feedback, if you were wrong you will have to walk back 2 miles the same way before you can even think about your next move. Agile/SCRUM/iterative workflows is such an overloaded term that everyone says so confidently with no consensus on what the fuck anyone is even talking about. Oh we have standups, IPM's, and retros, we must be agile lol. Love your channel btw I watch every video :)

Have been in both waterfallish and agilish environments the truth lies in the mushy middle. You’ll never get perfect requirements nor will you ever get leadership to lean into being agile and have flexible delivery timelines.

Thing is, most businesses already know this deep down. But it doesn't matter because the goal was never to actually build a good product, the goal was only ever cost control. Marketing will gussy up whatever turd gets shat out and it'll get sold to some sucker who has purchasing power but won't have to use the thing day to day.

really great explanation, it is true that it seems some of the points from the original paper are not considered nowadays, but the same happens with Ageil or Scrum, since it's difficult to apply a strict metodology and keeping with all the manifesto rules.

Few years from now, you'll have to make a similar video for scaled Agile. Btw, that preliminary build seems to be a POC.

Great video! Thank you for the history lesson. 🙂