Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We always end up with waterfall

amazingcto.com

Post reply on HN
Print view View original

11–20 of 144 posts

Re: We always end up with waterfall

#11

Post by adhesive_wombat »

jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

Everyone is vulnerable to it, but software developers are particularly prone to thinking that one true algorithmic "recipe" can be designed that leads to success if only it could be faithfully executed in the organisational CPU.

Re: We always end up with waterfall

#12

Post by SideburnsOfDoom »

mrmlz wrote: post #7
jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

Honestly I've never seen a waterfall model implemented without iterations. And you can always update the top-spec at later date if needed its just more difficult.. Which it should be.

> Honestly I've never seen a waterfall model implemented without iterations.

I have. It didn't reach the end.

Re: We always end up with waterfall

#13

Post by psunavy03 »

mrmlz wrote: post #5
pjmlp wrote: post #2

Easy, as somehow discussed on the article. Beyond the IT department everyone else has very to low incentives to adopt "those crazy ideas from computer guys", they care about deadlines, roadmaps, when marketing campaigns can be organised, with what content, what should be on the contracts with business partners,... Ever since we got those ideas around 2000, the best outcome if agile is adopted at all, is scrumfall as…

Yeah, because waterfall with iterations is better than SCRUM/AGILE/WHATEVER. God intended water to run from the TOP to the BOTTOM. Don't fight gravity.

[flagged]

Re: We always end up with waterfall

#14

Post by Earw0rm »

jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

Excellent comment.

I'd just add that scrum and waterfall are both more useful in explaining to management and junior engineers approximately how the team/project works, than in actually running the team/project.

Re: We always end up with waterfall

#15

Post by marcus_holmes »

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever.

The product is developed using waterfall and then it gets put in front of a stakeholder, who has changed their mind in the time between the initial spec and the delivery. So another, smaller, waterfall is created. This is iterative development. And it always happens, because no-one gets product development right first time.

We'd actually benefit from realising this. Which was the point of Agile - that you can change course during development and so develop the right thing through iteration. But Agile is (by definition) unpredictable. So you end up with this half-arsed solution that pretends to be predictable (except what it predicts is only the first iteration) and pretends to be Agile (except changing course is impossible) as the article says.

Re: We always end up with waterfall

#16

Post by [deleted] »

pjmlp wrote: post #2

Easy, as somehow discussed on the article. Beyond the IT department everyone else has very to low incentives to adopt "those crazy ideas from computer guys", they care about deadlines, roadmaps, when marketing campaigns can be organised, with what content, what should be on the contracts with business partners,... Ever since we got those ideas around 2000, the best outcome if agile is adopted at all, is scrumfall as…

[deleted]

Re: We always end up with waterfall

#17

Post by rstuart4133 »

The Zen of waterfall:

At some level everything is waterfall. If anything is to get done at all the programmer has to make a plan, then put his head down, arse up and implement it.

At another level nothing is waterfall. If the plan is successful it was shipped to the consumer (which may be the programmer himself), and it's very presence changes things for the consumer in ways that they didn't foresee. They then realise they need a new set of changes.

What we call waterfall model is really referring to the scale. If the plan is grand, the specifications for such a grand plan need to be detailed, the implementation long, and the time between putting the head down and evaluating results is large, and we call it waterfall.

But if the strategy is to explore the solution organically, the re-evaluations are frequent, the waterfall periods are short and we call the strategy something else.

So in the end everything uses waterfall. The programmer would not get the long periods of intense focus he need to be productive without it. But also nothing is waterfall, because no plan can foresee everything, it must be continually re-evaluated in the light of unexpected changes it brings as it is implemented.

From https://news.ycombinator.com/item?id=23970156 : by rstuart4133 on July 27, 2020

Re: We always end up with waterfall

#18

Post by docflabby »

I think problem is product managers are very common and probably unavoidable in most organisations.

Can't have product owners without actual ownership - without real equity in the product being developed do they really own anything?

Re: We always end up with waterfall

#19

Post by hnben »

choeger wrote: post #9

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…

> Waterfall doesn't mean not to iterate

I don't want to be pedantic, but waterfall does mean exactly that by definition (or at least it used to). There are plenty of variations, that include prototypes or MVPs or iterations (e.g. V-Model, Spiral model).

> waterfall is just the straw man of scrum zealots

You can't just change the definition of a word, and then call people using the original definition "zealots", see https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy

Re: We always end up with waterfall

#20

Post by JaumeGreen »

jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

> nobody advocates for balance and nuance.

Some people do, but they don't get the views or the support.

People are gregarious, they want to be part of a team, middle ground is not a team, unless you create a new name for it. People tend to give support to whoever hates what they hate, not to those who love what they love. So the middle team shouldn't be sold as "the good parts of A and B" but as "we hate A and B".

For example, in tabs vs spaces there's the "tab for indentation, spaces for alignment" bunch, that (we) usually try to sell it like "we use tabs, so you can set the viewing space as you need, and we use spaces so it's neatly aligned" and people don't listen to us.

What if we called it "tabspacing" and defended it like "spaces for indentation are wrong because there are people with visual impairments that need extra space to see things right, and just tabs are wrong, code looks ugly, also if you use space and tabs interchangeably it's wrong, the people with problems will see the code differently than the people without, there will be errors."? Then people might listen to us if they hate one of these things.

So yeah, that's why there are so many ways to do projects: waterfall, agile, scrum, kanban, scrumban, XP, ... .

Post reply on HN