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.

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!

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 ...

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...

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 would like to thank Christopher, He helped me pass software design patterns back in 2019. God bless you brother 🙏

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

Just wanted to say hi Christopher, and thank you for coming back to RU-vid. 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 RU-vid channel, by sharing your knowledge. Glad you are back, looking forward to more great concepts explained here! Great job

So glad you're back Christopher!

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.

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!

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.

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.

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

Hello Christopher we need more videos on code walks it is valuable so much

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 :)

It like medicine ❤ your content is so good man! Esecially the delivery. Unique!

Very nice topic and well presented!

Great video! Would love to hear more of your thoughts regarding development processes and frameworks.

Great video! Thank you for the history lesson. 🙂

Very rare on my experiences over 20 years in industry is taking care of requirements and design. The development department just gets five lines of a function the customer claims to need. While testing they come up with extended requirements that doesn’t fit into the design made. Budget has already run out of limit at this point. We switched to agile 10 years ago. The core problems haven’t been solved: Business Analysts keep going just to note requirements (rather than figuring out customers intention behind). Design doesn’t happen: „it’s not rocket science!“ There are then two types of programmers: a) I program literally what someone told me. b) I squeeze the business analysts to tell them what they have missed analysing and I am going to tell them what I am going to program that fits the gaps. Agile manifesto was like prophecy: Ideas that inspired many but only a few followed. „Collaboration“ became sessions and meetings without interest of understanding. „Iteration“ became multiple hot fixes after deployment. And while there is no documentation anymore (at least nobody takes care anymore), when you iterate, people start arguing from the beginning. By the way: customers haven’t changed. They want the perfect product on the first take. At time, in function, at quality, in budget.

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.

Great video!

i have never read the original paper but to my humble understanding, Waterfall makes sense in projects where requirements are basically "given" from the beginning and can't be changed without deep analysis e.g. in military applications etc.

I always thought I was a waterfall guy. Guess Im actually an iterative guy. The steps in waterfall make perfect sense and it also makes perfect sense to go back however many steps are required to make necessary adjustments.

Bro you are just awesome, i’m a software engineering students and i really enjoy and benefits from your videos, and i keep recommending it for my friends, you are awesome, keep it up bro, also i hope you talk about software architecture the same as you talked about software construction and also for software quality, Thank you ❤

Our old approach was to branch after each stage. For example, each system requirement set was divided into several software requirements routes. Each group had its own analysis and continued in the same mode. When things go wrong, hopefully we just have to scrap some routes. But the final integration was still painful.

Always love the concept! This is sounds like MVP then for the running soft dev?

Waterfall reminds me of the way British soldiers used to form up line abreast in the revolutionary war. Everyone knew it was stupid, but they did it anyway because their commander told them to do it.

My guy is back

The doing the thing twice approach, is the best approach I have found when Implementing a single user story, rather than the waterfall approach that devs usually take.

Author A criticizes the stodgy old methods, then a few years later, Author B criticizes Author A for exactly the same things. It happens in education- and probably every other field, too.

I would add that even the academics were designing these processes in the context of business managers who wanted the world to be top-down. These managers, especially those in big companies, wanted linear progress, with boxes to check off a list they could hand to their boss. We see this live on in Agile (tm), only with different incantations and religious police.

Operatons sounds cool, like Automatons that operate

Thank you, Christopher, for making these amazing videos. They are fascinating and engaging. Could you recommend books about Object-Oriented Design and Design Pattern? Can you make a book recommendation video. I think that would be a nice addition to your channel.

My current approach is IDEA -> TEST -> REPEAT. Ie start with a simple idea, test it, formate new idea, test, and so on. Follow your instinct, and choose new ideas and test based on where you feel the product needs refinement at that time. Then, once you've created a product which works, refactor the inevitable spaghetti. This 'follow the idea' approach is organic and flexible, and saves countless hours of premature optimisation. It's how ant colonies evolve, and how slime/fungul spores find optimal paths through complex networks.

I joined a project mid-90s, the team had spent 2 years already. I did some analysis and proved that they had bust performance limits. We scrapped everything, started over

agile is basically mini waterfalls so then you go from testing to requirements it will be cheaper

I completely agree. In my project I have had many testing examples that only then revealed a problem that required more design and analysis. To wait and do it all at "the end" is crazy to me. But I never listen to these people when they have these ideas so I'm a dangerous fella lol.

Software development is always my opinion vs your opinion. Nobody is correct. It's shuffling chairs around expecting different results. No development system meets expectations. This is why software development is still in its infancy. If it had 1000 years of history, like traditional construction and engineering, maybe it would be better.

I think waterfall is great if we know exactly what feature need to be implemented and they can't be changed one iota. What this means is waterfall can never, in practice, be done XD

it's for managers so they have something to do because they never get it wrong

waterfall works fine if its done right. Agile doesnt work either in that case

Wait, you mean scrum burn-down charts are a bad idea ? OF COURSE THEY ARE !

don't go chasing waterfalls.

I like ❤

Not because i cant do smth means i am incapable to do it. Maybe someone before me screwed it up.

Do it once, delete it. Do it again.

My advise to developers: Don't go chasing waterfall. Please stick to the iterative development process that you're used to. I know that you're gonna have it your way or nothing at all. But I think you're moving too fast.

its a pur Gold

So waterfall is just a fat scrum loop?

Yup, the Waterfall Method was only ever intended as a straw man.

do your job before doing mine

watarfall is still the best methodology

Is nice! I eh like iterative method very nice wawaweewa. Sorry 😅. No really great video. Waterfall is terrible

Waterfall is an option, as long as you don't mind your project becoming a total failure.

I was always perplexed why anyone ever tried to actually use a formal "waterfall" process (for anything larger than a simple small plan), never mind had to be convinced it is idiotic. Anyone who actually *does*… anything!… knows that nothing ever ever "goes on rails" like that. It's all constant and continuous feedback cycles. Is it computer science hubris or managerialism or what?

It works, you just don't know how to properly implemented.

Surprisingly, waterfall is still in use in the defence industry.