The Myth of the 'Waterfall' SDLC (2019) • Hacker News Board

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

#11

Post by chasd00 » Sat, Apr 10, 2021, 2:27 PM UTC

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,…

“client is not allowed to see” lol yeah that is so removed from reality as to be laughable. If I told a client you can’t see what we have the client would reply “ok, you can’t see a bank deposit until I get a demo of progress”.

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

#12

Post by specialist » Sat, Apr 10, 2021, 2:29 PM UTC

kstenerud wrote: post #8

Royce's waterfall model is what was actually being used until the mid-2000s in most software houses. And it was one of those processes that looks good on paper, but doesn't actually save you time or effort. I don't know where this "rigid" model comes from, but I never encountered it in the early days. Everyone knew you couldn't just complete a phase in totality and then move on to the next; there had to be overlap an…

Until 2010, I only worked in startups, small outfits. So I can't speak for "all software houses".

Speaking with refugees from megacorps, I do have the impression that bigger projects had different people (subteams) doing the different phases, with little overlap. I have no trouble imaging how that'd quickly become a Kafka nightmare.

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

#13

Post by wefarrell » Sat, Apr 10, 2021, 2:31 PM UTC

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 centipede model. In this model all of the vision, creativity, and flexibility stays with the head and the rest of the centipede just eats their shit. Developers can't see further than the next person's ass and have no idea why they are actually building the functional specifications that are fed to them. Implementation becomes completely disconnected from design which leads to compromised quality, missed deadlines, and products that miss the mark.

No task management framework is going to solve these problems.

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

#14

Post by kstenerud » Sat, Apr 10, 2021, 2:33 PM UTC

specialist wrote: post #12

kstenerud wrote: post #8

Royce's waterfall model is what was actually being used until the mid-2000s in most software houses. And it was one of those processes that looks good on paper, but doesn't actually save you time or effort. I don't know where this "rigid" model comes from, but I never encountered it in the early days. Everyone knew you couldn't just complete a phase in totality and then move on to the next; there had to be overlap an…

Until 2010, I only worked in startups, small outfits. So I can't speak for "all software houses". Speaking with refugees from megacorps, I do have the impression that bigger projects had different people (subteams) doing the different phases, with little overlap. I have no trouble imaging how that'd quickly become a Kafka nightmare.

You'd generally have PMs who had little contact with the engineering team proper. They'd take requirements from the execs, turn them into design documents, and then pass them to the engineering team to implement. So there would be a fair amount of friction, yeah. And lots of DFDs and ERDs that didn't match what was really happening ;-)

But then again nobody on the engineering team took them too seriously anyway, so it kind of worked out.

The main problem in those days was centralization of decision making at the top, where the decision makers had the least exposure to the reality on the ground. The military legacy of computer systems, I suppose...

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

#15

Post by specialist » Sat, Apr 10, 2021, 2:35 PM UTC

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…

Every successful project I've been on has narrowed scope approaching releases. Usually because new QA/QC work crowds out new features.

A bit like the KickStarter campaigns: bucket features into MVP, stretch goals, and bonus.

This was mitigated by having a tempo for releases, so everyone knew those extra features were coming soon.

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

#16

Post by bhawks » Sat, Apr 10, 2021, 2:35 PM UTC

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…

The sad fact is just how many organizations are so utterly dysfunctional and how many people follow the centipede model without even realizing it.

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

#17

Post by jk20 » Sat, Apr 10, 2021, 2:44 PM UTC

specialist wrote: post #10

Nice work. Agile Methodology was a self-defense coping measure for dealing with psychotic customers who cannot or will not do proper project management. It was never meant as a replacement for PMI. IMHO, "waterfall" is not having feedback loops, iteration. All of the methodologists (I read) in the 90s cautioned against "throwing it over the wall", as detailed in this OC's description of rigid sequences. Plenty of tod…

Agile is a fraudulent activity which exists only to provide job opportunities for mostly non-technical management in the form of pointless stand-ups and planning sessions. I have never seen it working in practice. Interestingly, it does not even work in theory, see e.g. the Agile manifesto full of dubious statements about "people over processes" and "maximizing the amount of work not done".

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

#18

Post by chasd00 » Sat, Apr 10, 2021, 2:46 PM UTC

specialist wrote: post #10

Nice work. Agile Methodology was a self-defense coping measure for dealing with psychotic customers who cannot or will not do proper project management. It was never meant as a replacement for PMI. IMHO, "waterfall" is not having feedback loops, iteration. All of the methodologists (I read) in the 90s cautioned against "throwing it over the wall", as detailed in this OC's description of rigid sequences. Plenty of tod…

A point often missed when talking about SLDC in client work is the client is a major factor in the success of the project and is not always up to the task. I can see how agile could be used as a way to cope with a difficult customer.

The thing with a client/customer work is the clock is ticking at a constant rate and the budget is decreasing at a variable rate. I’d like to research done on methods that try to ensure the two run out at the same time. If you finish on time with budget remaining you’ve left money on the table. If you run out of budget before the deadline you’re in the red. The goal is to run out of budget the moment you reach the deadline.

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

#19

Post by bckr » Sat, Apr 10, 2021, 2:55 PM UTC

> However, the situation was once the exact opposite. As Barry Boehm relates, On my first day on the job [in the 1950’s], my supervisor showed me a GD ERA 1103 computer, which filled a large room. He said, 'Now listen. We are paying $600 an hour for this computer and $2 an hour for you, and I want you to act accordingly'

Adjusted for inflation, this guy was earning on the order of $40k per year.

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

#20

Post by _y5hn » Sat, Apr 10, 2021, 2:57 PM UTC

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.