Waterfall gets an unnecessarily bad rap.

Nobody who delivers any system professionally thinks it’s a bad thing to plan out and codify every piece of the problem you’re trying to solve.

That’s part of what waterfall advocates for. Write a spec, and decompose to tasks until you can implement each piece in code.

Where the model breaks - and what software developers rightly hate - is unnecessarily rigid specifications.

If your project’s acceptance criteria are bound by a spec that has tasked you with the impossible, while simultaneously being impossible to change, then you, the dev, are screwed. This is doubly true in cases where you might not get to implementing the spec until months after the spec has been written - in which case, the spec has calcified into something immutable in stakeholders’ minds.

Agile is frequently used by weak product people and lousy project managers as an excuse to “figure it out when we get there”. It puts off any kind of strategic planning or decision making until the last possible second.

I’ve lost track of the number of times that this has caused rework in projects I’ve worked on.

▲

pydry 3 hours ago | parent [-]

>That’s part of what waterfall advocates for. Write a spec, and decompose to tasks until you can implement each piece in code.

That's what agile advocates for too. The difference is purely in how much spec you write before you start implementing.

Waterfall says specify the whole milestone up front before developing. Agile says create the minimum viable spec before implementing and then getting back to iterating on the spec again straight after putting it into a customer's hands.

Waterfall doesnt really get a bad rap it doesnt deserve. The longer those feedback loops are the more scope you have for fucking up and not dealing with it quickly enough.

	▲	vjvjvjvjghv 3 hours ago \| parent \| next [-]
		I don’t think this whole distinction between waterfall and agile really exists. They are more like caricatures of what really happens. You have always had leader who could guide a project in a reasonable way, plan as much as necessary, respond to changes and keep everything on track. And you have people who did the opposite. There are plenty of agile teams that refuse to respond to changes because “the sprint is already planned” which then causes other teams to get stuck waiting for the changes they need. or you have the next 8 sprints planned out in detail with no way to make changes. In the end you there is project management that can keep a project on track while also being able to adapt to change and others that aren’t able to do so and choose to hide behind some bureaucratic process. Has always existed and will keep existing no matter how you call it.
	▲	cushychicken 3 hours ago \| parent \| prev [-]
		>The difference is purely in how much spec you write before you start implementing. Ah, and therein lies the problem. I’ve seen companies frequently elect “none at all” as the right amount of spec to write. I’d rather have far too many specs than none.