They Knew Waterfall Didn't Work

Did you know that the paper that introduced the Waterfall method said that it is "risky and invites failure". They knew it didn't work.
💚 BUY MY BOOK:
leanpub.com/the-object-orient...
⚠️ Watch next:
• 3 Reasons WHY Waterfal...
🌟 Join the Patreon
/ christopherokhravi
📚 Recommended Reading:
geni.us/1obVBO (Essential Scrum)
📜 Royce, Winston. (1970). Managing the development of large software systems.
blog.jbrains.ca/assets/articl...

[@saschadibbern339]

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

[@gummansgubbe6225]

LUL

[@MusicByJC]

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.

[@JeffreyChadwell]

Same here on all accounts (including age). Man, I HATED flow charts.

[@gummansgubbe6225]

Same age, 25 year of SD. Never had to adhere to anyone. Always used my results delivered on time as my argument. Or as Watson-Watts wrote: "Give them the third best to go on with; the second best comes too late, the best never comes".

[@conall5434]

Just about to graduate, this is still the norm *sigh*

[@ipodtouch470]

Im a current student but I love me a flow chart. It doesn't need a standard but I love to solve the idea and have some documentation on a white board.

[@Templarfreak]

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.

[@ChristopherOkhravi]

I truly agree 100%. Very well put. Thank you very much for sharing. In the next video I will share some models that I find useful in terms of formalizing these thoughts. Stacey matrix is one and e-type systems is another. Thanks again!

[@Templarfreak]

@@ChristopherOkhravi cant wait :D

[@ApplicableProgramming]

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

[@fabiodbr]

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!

[@SkitzFist1]

So glad you're back Christopher!

[@mcebisisifundisetshula2207]

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

[@henrikmartensson2044]

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!

[@SimGunther]

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!

[@magnus49]

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

[@khatdubell]

Is that what he said? We must have gotten different videos.

[@TimoJohn]

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

[@FredGreen182]

Completely agree, and to add to that in most cases specifications will change DURING this process making the original analysis and design obsolete before the first line of code is event written!

[@georgesealy4706]

I never had problems with getting the requirements that were necessary for a feature set. I pressed back for clarity and a stable, complete set of requirements. I had to know what the code should do, and the QA people had to know what to test. There was too much at stake and too many people involved to make mistakes.

[@bogdanf6698]

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

[@gummansgubbe6225]

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.

[@ChristopherOkhravi]

Thank you very much for sharing your experiences. Much appreciated 🙏😊. We agree. Also, thank you for the sub and welcome 😊

[@svenkang7356]

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

[@user-qo9oy4re5e]

Very nice topic and well presented!

[@johnekare8376]

Great video! Thank you for the history lesson. 🙂

[@ChristopherOkhravi]

Thank you for watching 😊🙏

[@FredGreen182]

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

[@georgekhagan]

Great video!

[@javisartdesign]

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.

[@AntonioDoesMetal]

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

[@yahya220111]

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 ❤

[@ahmedmustafa4805]

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

[@georgesealy4706]

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.

[@leeris19]

My guy is back

[@zfold4702]

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

[@TheJulietteCharlie]

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.

[@chpsilva]

This! Very much this. Agile is beatiful but fatally flawed because assumes the customer is an allied. It's not. Everything else crumbles as consequence.

[@jasonpacker9607]

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.

[@chpsilva]

Also, the customer is never, EVER, your friend. He frequently doesn't know what he wants nor how he needs it, therefore the scope is pretty much open, during pretty much all the project duration. But he ALWAYS has a closed budget and a predefined timeline. And you have to make whatever you're doing fit on it. And that's why any interactive methodology never works, too.

[@liquidpebbles]

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.

[@Arsyel]

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

[@TheJulietteCharlie]

Be aware, that a MVP is in contrast to Prototype a piece of working software. That „piece“ can be huge. Even a MVP needs development methodology.

[@Arsyel]

I agree, its too simplified. But thats what I digest directly from its explained. Prototyping, or piece that represent of the overall work

[@Greenmarty]

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.

[@ChristopherOkhravi]

Completely agree. You might be interested in this other video on when Waterfall works: kzbin.info/www/bejne/r5nakpypiZWJiq8

[@AlexanderNecheff]

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.

[@PhysicsITGuy]

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.

[@PhysicsITGuy]

Like, check out what they wrote about the German support infantry: en.wikipedia.org/wiki/British_Army_during_the_American_Revolutionary_War#Foreign_units_in_British_service

[@GamalElkomy]

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.

[@ChristopherOkhravi]

Thank you for the kind words and for the specific request. I will certainly do that but need to gather my thoughts a bit more before I give a list of books. But it’s definitely on the list of coming videos. Thank you 🙏😊

[@zerg-zx5rx]

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.

[@ChristopherOkhravi]

Very interesting. Thank you for sharing this. 🙏

[@AlanMitchellAustralia]

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.

[@HKCS-yn5nc]

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.

[@ericpmoss]

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.

[@Palessan69]

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

[@jamesarthurkimbell]

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.

[@ghostradiodelete]

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.

[@ChristopherOkhravi]

😆

[@nickbarton3191]

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

[@kevalan1042]

Operatons sounds cool, like Automatons that operate

[@user-gh4lv2ub2j]

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

[@TheShorterboy]

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

[@potato9832]

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.

[@codewithstephen6576]

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

[@monad_tcp]

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

[@KX36]

don't go chasing waterfalls.

[@Msyo_Jaber]

I like ❤

[@Wildstraw]

its a pur Gold

[@professorfontanez]

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.

[@cristobalgajardovera5433]

Do it once, delete it. Do it again.

[@Wildstraw]

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

[@talideon]

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

[@torentoren]

So waterfall is just a fat scrum loop?

[@SteinGauslaaStrindhaug]

Scrum is usually waterfall in disguise. Everywhere I've worked where the claim of "doing scrum" was anything more than "we do agile, scrum, kanban or whatever", was basically waterfall with a lot of time wasting painfully slow all-meetings referred to as "stand up" (even though they often was for 10+ people and lasted at least 30 minutes; way more than my knees could tolerate; so I've always stubbornly sat down in the "stand ups") "sprint planning" or "planning poker" or whatever with all sorts of gimmicks like _actual_ overpriced playing cards and all sorts of silly rituals that had no relation or really impact on the actual work (beyond wasting 10-20% of the available time). Of course this was by necessity the largest companies I've been working for; tiny companies doesn't waste money on scrum certification and $ 50 planning poker card decks; small companies generally go for the "we do agile or whatever" approach; meaning they just let the developers figure it out; which actually works out to an organic functional iterative process as long as everyone involved is fairly competent and the managers are competent or lazy enough to leave us mostly alone.

[@khatdubell]

@@SteinGauslaaStrindhaug Pretty much every place i've worked someone brings up the term "scrumfall"

[@MusicByJC]

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

[@bopuc]

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?

[@ChristopherOkhravi]

I am similarly perplexed 😊

[@SteinGauslaaStrindhaug]

It's a pretty functional way to do routine stuff like (physical) engineering projects; where you're building a say a building that is very much exactly like hundreds of buildings you've made before. The problem is that software _isn't_ engineering in that way; it's actually always a research project! If you had made a piece of software before; you _don't_ need to write it again; you simply copy it.

[@khatdubell]

Probably because, prior to software, there was hardware, and that is how hardware engineering works. They just copied the idea for software development.

[@radiofedor]

watarfall is still the best methodology

[@Wildstraw]

do your job before doing mine

[@gerdsfargen6687]

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

[@AlfredoPinto]

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

[@where-is-my-mind.]

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