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

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

#31

Post by NotPavlovsDog » Sat, Apr 10, 2021, 3:59 PM UTC

throwawayboise wrote: post #28

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…

It's a model that allows contractors/consultants to declare a phase of the project "complete" and bill for it. And then to bill for change orders/rework after that. It's not about building good software, it's about making money building software.

Let's not forget upfront and arbitrary budget and time constraints from the customer side.

"We want the project to be delivered by X, and we have a budget of Y. Our specs are Z, but not really, so factor in A refactorings (A for arbitrary). Oh, and we don't have Q for Quality defined."

Especially prone in government and military contracts. Throw in some arbitrary public procurement rules so that Y is allegedly not disclosed, except to the select contractors that somehow know what the desired Y is and what the competition is bidding before bid close.

You get the F-35, which pragmatists say was never meant to fly, just to make the players rich in the process of failure.

Sauces: https://www.forbes.com/sites/davidaxe/2021/02/23/the-us-air-... https://pando.com/2015/09/24/war-nerd-why-f-35-albanian-mush...

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

#32

Post by specialist » Sat, Apr 10, 2021, 4:07 PM UTC

kstenerud wrote: post #14

specialist wrote: post #12

Earlier quoted context omitted.

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

Ya. I think that's just a very hard problem. Mostly due to scale running up against organizational psychology.

I helped a friend with some property tax software for governments. Trivially technically, almost intractable organizationally. Not for me. I deeply respect the people who can swim those waters.

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

#33

Post by mcclung » Sat, Apr 10, 2021, 4:38 PM UTC

I can remember way back around 1990 being told that waterfall was mostly a bad idea, and few shops really followed it. Rapid prototyping was agile back then. We were shown how to produce flow charts and static call diagrams in Software Engineering 201 or whatever it was called, and I felt they were doing it to show us how but also to demonstrate how much work it was, and how easy it was to get the analysis wrong.

As new fashions arose, instead of attacking waterfall as practiced (which, don't get me wrong, is still labor intensive), they criticized a straw man version, because it made the new methods look even better.

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

#34

Post by stevegalla » Sat, Apr 10, 2021, 4:56 PM UTC

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…

> Does this lead to the same sort of problems with the development of physical systems?

I would argue that physical systems aren’t developed in a “waterfall” method.

In mechanical design classes in engineering school, we learned to start with low fidelity sketches to capture customer intent. We come up with several options, build those into increasingly higher fidelity 3D models, use simulation to refine, take a few candidates and get physical prototypes, do physical testing (strength, endurance, integration, etc.), determine the best one, then go into limited production to prove out and establish the production process, then go into full production.

We are taught (and in the automotive industry it’s a requirement) to have cross functional teams involved in the design stages of both the item and the manufacturing process.

To your point about inadequate spec: My opinion is there are so many different backgrounds coming into software that there is no common language or background.

I think everyone thinks their way is better and it’s hard to communicate technical ideas when you need to constantly recreate and translate between terminology and documentation methods. This lack of convergence and common knowledge is what I think results in poor specs.

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

#35

Post by datavirtue » Sat, Apr 10, 2021, 5:01 PM UTC

This is absolute gold but we need a simple and compelling story that can be told before it will inform the masses. Agile tried but seemed to miss the point of Conway's Law that organizational structure or communication paths influence the design. Agile was trying to change or work around that fact.

Companies like Oracle are cargo-culting by building cloud platforms that resemble AWS but they have no appreciation that Amazon changed their internal communication practices resulting in AWS! Oracle isn't going to do that, perhaps they can't. Has Microsoft adapted their communication structure and is it reflected in their cloud platform?

What I find interesting is that cloud service adoption is allowing silos inside companies to avoid the structures that impede them--to some extent.

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

#36

Post by datavirtue » Sat, Apr 10, 2021, 5:07 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,…

It's a compelling simple story for the decision makers that only requires them to spend other people's money and avoid changing themselves or their organization. Irresistible.

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

#37

Post by Tagbert » Sat, Apr 10, 2021, 5:13 PM UTC

anodari wrote: post #30

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…

I call this the problem of noise and loss of information. If someone has to write a specification and move on to another one, there will be a noise. Imagine customer -> product -> analyst / ux -> dev. etc. At each level, a little bit of information is lost. One possible solution is that the devs. are partly involved in all phases of the specification and design. This could reduce the problem of noise and loss.

One way to fight information loss is through error correction. That means a feedback loop between the stages in this process where downstream results are reviewed by upstream actors to evaluate their suitability. Agile tries to build that in by iterative work, demos, and retrospectives.

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

#38

Post by [deleted] » Sat, Apr 10, 2021, 5:14 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…

[deleted]

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

#39

Post by jiveturkey » Sat, Apr 10, 2021, 5:16 PM UTC

cmrdporcupine wrote: post #21

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…

It's not strictly an artifact of BigCorp From The Past. Frankly this model is what has been followed in most teams I've been on at Google, well into this part of the 21st century. PRD -> design doc -> code -> launch -> promotion. Of course, it's broken down and full of a mess (like a real waterfall) at most stages. I feel like in a way it was a disservice to my career having a decade and a bit of work in smaller comp…

you might be attaching too much importance to shipping quickly. being promoted quickly is the metric of importance

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

#40

Post by spaetzleesser » Sat, Apr 10, 2021, 5:18 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,…

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/