- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
I heard nasa used to do some kind of TDD lol
Waterfall: Boeing/ULA does this. Their rockets cost $4B per launch, don’t work, strand astronauts. Maybe the next repair/test cycle, if management’s dumb enough to keep paying them.
Agile at least launches something.
Waterfall is more like: You want to go to Mars. You start to build the rocket. Managers that don’t know anything about building a rocket starts having meetings to tell the engineers who do know how to build a rocket what they should be doing. Management decides to launch the rocket based on a timeline that’s not based in reality. Management tries to launch the rocket based on the timeline instead of when it’s actually finished. Rocket explodes. Management blames the engineers.
The various methodologies don’t actually change what the engineers need to do. But some of them can be effective at requiring more effort from management to interfere in the project. Bad managers are lazy so they’re not going to write a card, so they can be somewhat effective in neutralizing micromanagement. I say somewhat, because bad management will eventually find a way to screw things up.
More accurately the waterfall mission ends up on Phobos only to have to scramble to figure out how to land on Titan because the customer can’t tell the difference between moons
Oh yes, everyone know that waterfall works and the rest sucks, nice
If the shoe fits …
A good team can make any of these strategies work. A bad team will make a mockery out of them all. Most teams are neither good or bad, and stumble forward, or backwards, doing the motions
They forgot the bit where the Waterfall method blew through the budget and deadline about five times over.
And it turns out the customer actually needed a blender
This is why I always act as if neither exists
A software engineer was not involved in this if waterfall is painted positively.
I think the last time I heard an engineer unironically advocating for a waterfall IRL was about a decade ago and they were the one of the crab-in-a-bucket, I-refuse-to-learn-anything-new types—with that being the very obvious motivation for their push-back.
Of course because they don’t like being held to estimates and deadlines.
…and when you agree to run it Agile, which calls for closer and continual communications with the users, the first thing they want is a rep to do it for them .
No,
Serious teams know that building big software is hard and that starting by having a set deadline is the first failure point of a project.
Serious team wants a set budget and feature set. They also want a dialog with the aquiring party, because as you dig deeper in the software you uncover oddities. These oddities are more often than not a failure of the aquiring party understanding of their own business operations.
And thus, a serious team will help the aquiring party refine their business process by either removing useless steps, adding missings steps or changing a step in the overall workflow. And that’s were the most of the value of making a new software comes from.
Doing waterfall will stop this from happening and will remove actual value from the software because it’s going to be bloated with useless things that were badly understood by the aquiring party.
Agile is about producing as much value as possible, as fast as possible, in a set budget.
English is my third language so sorry if it’s hard to understand or feel aggressive.
Yes, silly engineers that don’t like being held to unrealistic estimates and deadlines; typically the ones that arise at the start of a project where there are still who-knows-how-many unknowns to find.
Waterfall is the most effective tool for software engineering in a world where the whole world stops once you’ve planned and only starts again once the project has finished—i.e. a fictional world that doesn’t exist. Literally every waterfall project I worked on back in the old days was derailed because something happened that wasn’t planned for—because planning for everything up front is impossible and planning for anything more than a handful of eventualities is impractical.
Agile and subsequent methodology comes from realising that requirements will change and that you are better off accepting that fact at the time than having to face it once you’re at the end of the current road.
Agile does not mean engineers talking continuously to the users, engineers are hired to do what they’re good at: engineering. Understanding user requirements and turning that into a plan has always been product’s job regardless of methodology, in agile and similar it’s just spread out over the duration of the project, not front loaded. Agile isn’t “make the engineers do every proficiency”.
And here I am, running projects for the past 20 years mostly using agile, and still very much unconvinced about its supposed superiority over waterfall.
Waterfall: Spend 10 years compiling written functional and technical requirements. Cancel the program due to budget overrun.
Yeah, waterfall would be “you collect requirements to build a rocket to Mars, 2 years later you have a rocket to Venus and it turns out they didn’t think oxygen is essential, they’ll have to add that in the next major release.”
What’s not covered is the 25 years of R&D in advance of waterfall project starting, or that it’s delivered 200% over time and cost due to those requirements being insufficient and based on assumptions that were never or are no longer true.
But at least the rocket has an opulent ball room as per the design spec
Test-driven development: You spend all your time building a gizmo to tell you if you’re on Mars or not. A week before the deadline you start frantically building a rocket.
TBF the analogy is especially strained for that one. Per another commenter, Boeing actually makes rockets with waterfall, but test-driven only really makes sense for software, where making local changes is easy but managing complexity is hard.
Edit: Actually, there’s even software where it doesn’t work well. A lot of scientific-type computing is hard to check until it’s run all the way through.
These are all accurate, except the first Waterfall one, who also doesn’t go to Mars.
Right. They design the whole rocket, spend years to build the rocket exactly according to the design doc, then the rocket explodes on the launchpad and they have to start all over.
That’s why testing comes before launching.
So, we need waterfall testing to be separated?
The build phase took too much time, you now have 1 day to test all the features and design elements of the rocket, because launch day is tomorrow. Good luck!
Seems biased… What’s that logo they’re trying to hide in the top-right?
Toggl’s old logo.
Must be OP trying to hide it, Toggl displayed it proudly. The author used to work for Toggl marketing and ask can be seen from this post, did an excellent job. He still has a webcomic, it’s just not marketing for Toggl anymore. Here it is
As for bias - it’s a time tracking tool, but I don’t think they actually shill for waterfall, I think it’s just poking fun at the agile methodologies.
The Agile Development here is the same result I’ve experienced for every one of these methods. Mostly because of clients/management.
That’s why agile was created. Because people don’t know what they want in panel 1.
Scrum is about transparency, not intransparency for a month
Scrum is not about any of the things that Scrum proponents claim it’s about.
Specifically, it’s not about agility, it’s not about velocity, it’s not about quality, it’s not about including the “customer”, and it’s only about a kind of transparency that has absolutely no impact on the final product.
But yeah, it’s about some kind of transparency.
Specifically, you would have to put in effort to be more wrong.
Go read the scrum manifest.
In reality, companies always adapt for what they think suits them. Very rarely do you actually use scrum completely as intended, that’s fine. But you don’t blame the cow when the cook burned your steak. You blame the cook.
Oh, Scrum has a manifesto now? Where is it?
Or you meant the Agile manifesto, that Scrum breaks half the items and does nothing about the other half?
Perhaps poorly translated, they call it the scrum guide in English
https://scrumguides.org/scrum-guide.html
I don’t know what parts you are talking about since you’re not specific.
Furthermore. Kanban is just a method of keeping track of who does what and what the progress of that is. You can use kanban in waterfall. You can use kanban in scrum. No one is just using kanban and nothing else. As your post seems to think.
Seems like the author has never programmed anything
pretty sure they’re saying waterfall for building a rocket because that’s literally how NASA builds a rocket, including the software. It’s terrible for building anything other than a rocket though, because the stakes aren’t high for most other projects, at least not in the way that a critical mistake will be incredibly bad.
i take you have never heard of the V-model. basically you climb the waterfall back up to verify everything. most things that fly within the atmosphere are done that way. pretty sure NASA would do the same.
You’re right I haven’t heard of that model, but NASA has documented pretty well that it follows waterfall. https://appel.nasa.gov/2018/11/27/spotlight-on-lessons-learned-aligning-system-development-models-with-insight-approaches/
You can assume people here know what waterfall and the V model are.
Depends. I’ve heard management talk about agile and waterfall, but I’ve not heard even one manager say V model.
I’m glad I’m not alone. I couldn’t make sense of this comic.
I’m getting pretty old so I have experienced multiple waterfall projects. The comic should be
You want to go to mars You spend 3 months designing a rocket You spend 6 months building a rocket You spend a month testing the rocket and notice there is a critical desing flaw.
You start over again with a new design and work on it for 2 months You spend another 6 months building it You spend 2 months testing
Rocket works fine now, but multiple other companies already have been to Mars, so no need to even go anymore.
This is the perfect waterfall analogy.
Yeah, but waterfall requires that management knows what they want. It’s impossible!
So often it’s patience from stakeholders to allow for time to actually design and build the things, or willingness to admit the actual cost, or an impossible grand vision with an unqualified/understaffed team, and of course reprioritizing constantly as if it’s easy to resume later without paying ramp up.
Don’t get me started on the constant detailed status reports…
This but unironically
I don’t think that they were being ironic…
Yeah, it requires replacing the “you test the rocket” with “you test the rocket and it fails or doesn’t meet the updated mission specifications” and the “you go to mars” with “you want to go to mars”
