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

51–60 of 144 posts

Re: We always end up with waterfall

#51

Post by phreack »

doctor_eval wrote: post #21
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 Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

This is it, I distinctly recall a reading a paper defining Waterfall as a thought exercise, with the author coming back years later to clarify that there can never be such a thing in software development. The Wikipedia article for "Waterfall model" mentions something like that as well. As an old teacher used to say, "There's no such thing as a Waterfall model, it was your parents all along. All software development is iterative."

Re: We always end up with waterfall

#52

Post by BLKNSLVR »

Purely my anecdotal experience:

Everything tends to waterfall because the natural human "thing" is to create a process which can be repeated to ensure success / quality / . If Agile thing worked, let's package it up into something repeatable and follow that to the letter... Oh, waterfall.

Agile requires constantly working against that, which is hard, because Managers want and love safe and predictable and measurable against something concrete.

Make a framework rather than a process, but that's a fine line.

Agile ultimately needs trust in the team to be able to think on their feet for every scenario coming into their board. I'm my experience this trust either didn't exist, or is treated as a second class citizen to said safe, predicable, measurable, repeatable process.

And I don't believe necessarily that Agile is the be all and end all.

Re: We always end up with waterfall

#53

Post by shalmanese »

Waterfall is the default resting state of software development same as how _v3_final_FINAL_newedits_Finalv4_revised.doc is the default resting state of version control. It takes active energy to move away from that state and things inevitably drift back towards it without continued application of discipline.

Re: We always end up with waterfall

#54

Post by BLKNSLVR »

andyjohnson0 wrote: post #40
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…

> The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. I'm feeling grumpy and decaffinated this morning, so I'll just note that you can't sell books and courses and conferences on "balance and nuance".

You should be grumpy and decaffeinated more often, them's the cracks through which the truth shines.

Re: We always end up with waterfall

#55

Post by goodlinks »

SideburnsOfDoom wrote: post #37
goodlinks wrote: post #28

Earlier quoted context omitted.

There needs to be a stable narrative to shareholders, anything within your control should be managed. Moving all software development into some kind of skunkworks part of the business with 0 expected returns and only ever discussing roll outs may be one way to do it. (Shrug) Its why i think innovation is maybe a bit easier at a privately held or government owned org. They can look at the value more directly rather th…

> There needs to be a stable narrative to shareholders I don't disagree with that. In fact, knowing the end goal is even more important when actions are "skunkworks". > Moving all software development into part of the business with 0 expected returns Agile's focus on "Working software is the primary measure of progress. ... early and continuous delivery of valuable software." is IMHO the opposite of that characterisa…

Agreed. Software development and basically all efficiency / process improvements are not really top down at all.

I just think that anything not top down doesnt play nice with shareholders. Also doesnt play nice with management that want to say they are the ones that got something delivired.

Seeing projects get rejected as they delivier too much of an improvement (e.g. we only predicted 5% savings this is likely to give 40%) really opened my eyes to how important it is to appear like you are more in control than you are.

On the skunkworks suggestion, i was meaning dont put anything from that team into any forecasts until you have a better measure of the impact.that way you controlthe narative better.

Re: We always end up with waterfall

#56

Post by Blaiz0r »

doctor_eval wrote: post #21
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 Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

Winston Royce actually did have an iterative process as part of Waterfall, it was in his final model, and the diagram was on the next page of the document that most people fail to recognise.

https://upload.wikimedia.org/wikipedia/commons/d/de/1970_Roy...

Re: We always end up with waterfall

#57

Post by leokennis »

spinningarrow wrote: post #46
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…

> scrum is too much Surely scrum is too little? Most lowercase-a agile people consider it more of a stepping stone into agile.

Just out of curiosity, are there any non-startup non-tiny companies whose core business is self built software (or a service that runs on said software) that _actually_ and _in practice_ follow the agile manifesto?

Re: We always end up with waterfall

#58

Post by doctor_eval »

Blaiz0r wrote: post #56
doctor_eval wrote: post #21

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

Winston Royce actually did have an iterative process as part of Waterfall, it was in his final model, and the diagram was on the next page of the document that most people fail to recognise. https://upload.wikimedia.org/wikipedia/commons/d/de/1970_Roy...

My recollection from the paper is that he presented what’s typically discussed as waterfall at the start of the paper, and from there developed the iterative process.

Neither process was explicitly called “waterwall” - and the former is what I was taught at software engineering school.

Re: We always end up with waterfall

#59

Post by doctor_eval »

hhlevnjak2 wrote: post #25
doctor_eval wrote: post #21

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

> The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with I worked as an external employee in an environment that had a very functional scrum implementation. You had groomings, plannings, dailys, retrospectives. Every task was defined, estimated, time on them tracked to get better in estimating. You had scrum masters, capacity plannings. On the surface, it wa…

Yes, exactly this.

I saw a quote recently from Erik Dietrich that said, "A lot of people mistake activity for productivity” and that describes every scrum implementation I’ve ever seen.

It’s a cargo cult, no doubt in my mind.

Re: We always end up with waterfall

#60

Post by doctor_eval »

The_Colonel wrote: post #24
doctor_eval wrote: post #21

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

> But waterfall itself was a straw man I disagree. I've been in many projects which looked exactly like the stereotypical waterfall, with the expected results (delays, death marches).

You misunderstand, the idealised waterfall model was literally presented as a straw man.

The horror is that it got picked up as a legitimate SDLC. Hence your exposure to it.

It’s almost like they saw the pictures and didn’t read the words.

Post reply on HN