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

The Myth of the 'Waterfall' SDLC (2019)

bawiki.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: The Myth of the 'Waterfall' SDLC (2019)

#41

Post by spaetzleesser »

Yhippa wrote: post #2

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was done. Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn't consider. The project was somewhat of a legacy refactor so it was easy…

Yeah. I don’t understand why people like to jump from one extreme ideology to another extreme. First it was “plan everything ahead in detail” which then got converted to “plan nothing ahead”. Both are insane and don’t work. I always ask where the decision makers see a project in maybe 3-5 years. Having that long term vision gives a lot of insight into possible software architecture decisions. You still can make changes but at least the general direction is right.

Re: The Myth of the 'Waterfall' SDLC (2019)

#42

Post by spaetzleesser »

_y5hn wrote: post #20
Yhippa wrote: post #2

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was done. Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn't consider. The project was somewhat of a legacy refactor so it was easy…

Once devs and testers get traction in their work, what happens is business slacking off. Then when approaching hard dates, stakeholders suddenly wake up and demand changes to everything, often just to leave marks or to hide they dozed off. This even though agreed upon scope. Keeping this in line demands PM skills, contrary to agility. No process will save people from themselves.

Very true. The decision makers kick something, fall asleep during the work and then start to panic close to the end. Agile would require constant engagement by the business people which I have seen very rarely.

Re: The Myth of the 'Waterfall' SDLC (2019)

#43

Post by jiveturkey »

_y5hn wrote: post #20
Yhippa wrote: post #2

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was done. Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn't consider. The project was somewhat of a legacy refactor so it was easy…

Once devs and testers get traction in their work, what happens is business slacking off. Then when approaching hard dates, stakeholders suddenly wake up and demand changes to everything, often just to leave marks or to hide they dozed off. This even though agreed upon scope. Keeping this in line demands PM skills, contrary to agility. No process will save people from themselves.

well said

Re: The Myth of the 'Waterfall' SDLC (2019)

#44

Post by Ma8ee »

throwawayboise wrote: post #26
wefarrell wrote: post #13

The problem with software development methodologies is they are sold as a solution for problems that arise from organizational/cultural dysfunctions. Up front analysis is not the problem, the problem is that the people charged with implantation are not given the big picture view and the flexibility to adapt the solution. Instead of using the term waterfall as the counterpoint of agile I prefer to call it the human ce…

Is it just a problem of inadequate specification? Because the methodology seems to work with physical systems. If I design a machine, and I need a gear or a cam or even a more complex component, I can send the specifications for that part to a machinist who knows nothing about the "big picture" of what I am building. Yet he can make that part of it to perfection. Does this lead to the same sort of problems with the d…

The problem with comparing software development with manufacturing physical artifacts is that the phases are mixed up. The manufacturing, creating the artifact, in the case of software, is a wholly automated process usually done by a compiler (or similar). The compiler doesn’t need to know shit about the big picture and usually produces the artifact exactly as specified, as your machinist.

So software development are all about writing down the specifications precisely enough for the compiler to create the artifact. Mixing up this process with manufacturing is a source of many of the problems in software development.

Re: The Myth of the 'Waterfall' SDLC (2019)

#45

Post by Yhippa »

marcosdumay wrote: post #23
Yhippa wrote: post #2

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn't have hard due dates. The thing was done when it was done. Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn't consider. The project was somewhat of a legacy refactor so it was easy…

What you needed was somebody empowered to judge the cost-benefit of those requirements and disallow low gain ones. (And if they were all high benefit, then things were just working as they should.) If you tried to collect the requirements up-front, the only thing you would get would be to either stall the project before it starts (what could be a good thing), or to do the exact same process, but only after a months-l…

I agree with you and I definitely don't think the up-front approach is great. I just wish there was a way to have some kind of forward thinking instead of low-gain requirements in that randomly appear.

Re: The Myth of the 'Waterfall' SDLC (2019)

#46

Post by Izkata »

spaetzleesser wrote: post #40
trabant00 wrote: post #7

I recently took a mandatory SAFe course. The introduction consisted of mainly justifying the practice by comparing it to the waterfall method. The latter being defined absolutely ridiculos. The client is not allowed to see incremental versions until the entire thing is completely finalized, maybe 2 years later. The initial design is not allowed to be altered. Testing can't start until the entire application is done,…

You just have to look at the SAFe diagram to see that it’s complete insanity. Basically the pipe dream of managers who want a fully automated, predictable process. https://www.scaledagileframework.com/

I like how, outside of the central diagram, there's random buzzwords not connected to anything.
Post reply on HN