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.
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.
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.”
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 .
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”.
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.
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.
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.
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.”
Waterfall: Spend 10 years compiling written functional and technical requirements. Cancel the program due to budget overrun.
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 .
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”.
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.