3 Reasons WHY Waterfall Doesn't Work
Вставка
- Опубліковано 4 чер 2024
- Three simple models that explain why and when the Waterfall method cannot work.
🎓 References:
- geni.us/1obVBO [Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular Agile process. Addison-Wesley., Fig. 3.7]
- users.ece.utexas.edu/~perry/e... [Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060-1076.]
Watch before: • They Knew Waterfall Di...
Watch next: • 7 Tips to Grow as a De...
Contents:
00:00 Intro
00:26 Requirements vs Knowledge
02:00 System Types
06:50 Stacey Matrix
11:17 Outro
Even my simple college projects rarely stayed static. There's so much that I don't know that I don't know at the beginning of the projects to give any kind of accurate prediction of what it would be like to actually complete them, assuming I was making something new. It's also difficult to make sure everyone on a project has the same goals in mind from the very beginning.
The way I have thought of this is, for example, S-Type systems tend to be very, very, small and/or is a representation of something that existed before. For instance, a media player. There hasn't been a significant change in decades on what kind of functions should be supported by such system. At the very minimum, you will need to support the ability to:
1) playback
2) pause
3) stop
4) rewind (or skip back)
5) fast forward (or skip forward)
6) change tracks (either by one back or forward, but also by selecting a track number)
That said, I imagine that, at some point, such a system started as an E-System (or even a P-Type). Basically, given time, I think P-Type and E-Type systems could morph into a specifiable type system because enough knowledge about what such systems should do has been accumulated.
I engineered custom vehicles in a previous life. Part of the vehicle requirements were S-type (strict government regulations, standard vehicle dynamics, etc.), part P-type and part E-type (ex. subject to evolving customer needs). Your guide is great: we would have done better to focus on the S-type problems first, then P-type, lastly E-type.
Thank you very much for sharing these interesting experiences. Much appreciated 😊🙏
A long time ago I followed a radio program series called "The hunt for the perfect language" (directly translated from Norwegian). They talked about different times, places and religion and their languages. In the end they ended up with Esperanto. A language that as I remember it just add the necessary specifiers as new knowledge is gained. Their final conclusion was that you cant have a perfect language without prefect knowledge.
I'd say embedded-in-hardware systems have to have up-front specifications to some degree. How do you build the hardware on time and budget if you don't know what you're going to need? And if you don't know what the software needs to do, how do you know the MCU you picked isn't either too wimpy or you're paying for power you'll never need?
I may be repeting myself a little bit here, but I really do like your videos, they're interesting, clear and engaging. One of the things I appreciate most is when you add bibliographic references, thus allowing people to dive deeper on the topic and to discover/rediscover some of the milestones of CS fundamentals. Thanks!
Thank you very much. Also, thank you for reminding me about references since I had forgotten to add them to the description 😊
Loving your content... thank you!
As usual, very good content.
Awesome video! Good to know what was done before so we can try and not repeat our mistakes
My man!❤
This is really good. Could you potentially drop the links to the papers for these 3?
Apologies for the oversight. References added to the description. The Stacey Matrix is not specifically discussed in Rubin (2012) but Cynefin is discussed and that framework is very similar. The way I discuss the Stacey Matrix is a more informal, but very common, way that the diagram is used. Thank you very much for letting me know that I forgot the references 😊
The trick is convincing the PM that you're working on an E-type. "Well you're just doing the thing aren't you?"
I'm working with B-Type system, B the first to comment Type system
I had a thought just now watching this video and I am just putting it out there as a food for thought. In order to defend a waterfall approach to all of these kinds of application types it must be shown that
All S-type system can be combined in such a way that the combined system is still an S-type system.
All P-type system are reducible to combinations of S-type systems.
All E-type systems are reducible to combinations of P-type systems.
From these statements it follows that all systems regardless of type are suitable for waterfall since they are all reducible to combinations of S-type system which are all formally specifiable. Now the question that is more tricky: even if this was possible, might there still not be a problem of feasibility, i.e even if every system is reducible thus, might it not still be the case that such an exhaustive analysis into S-type systems cannot be done in a reasonably finite time frame. Might it not still be that the time it takes to perform this analysis is measured in thousands of years, even for a AI powered computer? 😂
If you want your development studio to go bankrupt before you ever get out of the specification phase of your first project, sure :)
Big daddy back in action!!! ❤
Excellent. Where did you find this analysis about the waterfall approach? Any articles or books that worth to be read? Thx you for your channel. I love it.
Thank you very much. The analysis is essentially compiled by me and resembles how I teach this in my university lectures 😊 Thank you for reminding me about articles and books. I have added references to the description! Apologies for the oversight. I highly recommend "Essential Scrum" if you want to dive deeper into this. Thanks for watching 😊
Can you make a video talking about type of the systems especially, i think it will be cool 😁👍🏻
In one of the projects I am working on we actually started with writing down specs but as the month went by we got more and more specs. But that what we wrote stayed, no flipping back and redo something. It is a very complex project, so I am a bit confused now. Let me sleep on it.
Wouldn't there be an argument that the first example of systems, are indeed fundamental to the E-type systems. Looking at early systems most were S- type to begin with. Doing computations, through switchboard, breadboards, analog computers (looking more like machines), mostly used in specific problem solving on punch cards in the earliest formats 😊. At least I'm sure that's a qualifying example of an S-type, correct?
Later came electronics, and digital/analog displays (early integrated graphics chips P-type was used to implement not knowing all the specific calculations, or complex matrices for raster graphics to display more than dots in various scales and limited colors, back then dithered for FX 😊), but back to the implement of the internet, which early on was a combination of P-type for networking, and S-type for addressing. Most modern platforms using the E-type with the other two types integrated throughout, save the core CPU functions, Bios, Partitioned memory for Startup checks, and registers, most are S-type in direct application, but have a back end to change the parameters. In which I'd refer to as P-type being unspecified, not taking into account the front end S-types required to run the computer, well crashes it if you don't know exactly what your doing. Had to learn that the hard way 😂.
Amazing video Christopher. Super applicable to other areas of engineering too.
I suspect I might actually be working on a P-type system, given that my pet project is a superhuman chess engine (or AI, to fancy it up a bit). So perhaps it's not that extremely rare 😂
this is gold, you just kill off any reason why you would use OOP, as it is only usable in the simple zone, anything else, you can't plan objects and interfaces up front, you need a structure that can change more FP-like.(FP also got problems)
So the only thing we'd have to worry about is the formulas and their call order changing instead of having everything about the software change 😂
No, it has nothing to do with whether you're using OOP or FP. Both can be made to easily change, depending on how you design it
@@detaaditya6237 if you do OOP the "right" way than this is a big no, you need to design class diagrams, and you need to make sub classes and object only got 1 part of the state, and when you refactor that kind of system aka true OOP, then you need to start finding your changes by remaking your class diagram,(else why have it), and then you need to cut into a lot of classes, you need to add/remove full sub classes, where if you don't do that, but you code after what is needed now, then it is a lot of small changes.
in a program that changes spec every day, there only thing you can use Object for is to hold data that belong together.
a lot of software fail, a big % of them is because OOP, and the structure that is hard to change, and the tech debt from changes class chains.
My life is in the anarchy zone.
Embedded software systems can sometimes be s-type problems but even these don't work with waterfall. The only thing to takeaway from waterfall is understand your inputs and define your outputs
TLC tried to warn yall about this back in 1994...
😆
How many more videos are we getting with waterfall in the title? I'd like to know when I can return to watching your videos.
Don’t worry its the last one 😄
Did you just ask for an estimate before requirements were specified?
That's pretty meta.
@@AlexanderNecheff😆😆 (which also means that my estimate must be wrong)
I would argue that this video was only tangentially related to waterfall but it served as a good framing device to talk about e-type, p-type, and s-type systems. If you care about that topic it may be worth a watch.
Who is this video for? I've not seen someone promoting or using waterfall for more than a decade. You'd better explain the real pitfalls of agile or why PMs want to estimate in story points that are "definitely not hour equivalents" but still map onto a timeframe limit.
Nobody admits to being a crackhead... or using waterfall.
Well, they don’t call it waterfall, but in most of the regulated fields (automotive, healthcare, aerospace, military, …) they basically work that way. V-model is often used or even required.
I love the video. It reminds me of what not to do and reevaualte my process. Do your own video then and let’s see how that works.
Many companies try to call their waterfall-like processes agile.
We do use it to some extend
, especially in poc