Even with Agile and Scrum waterfall will sneak in • Hacker News Board

Re: Even with Agile and Scrum waterfall will sneak in

#61

Post by boffinAudio » Mon, Dec 06, 2021, 11:36 AM UTC

Iv wrote: post #23

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

I was once explained the interest of quick iteration cycles (the main opposition, IMO, to a waterfall model) in a simple way: The teacher drew a very simple chart : y = t. "This is, in a given project lasting from t=0 to t=1, the amount of practical information that you have about how to design this project. At t=1.0, you have 100% of the information. When you start, you have about zero information about it, just gue…

Waterfall can be fast. In fact, done properly, it is the fastest technique of them all.

Re: Even with Agile and Scrum waterfall will sneak in

#62

Post by lelanthran » Mon, Dec 06, 2021, 11:37 AM UTC

db48x wrote: post #49

lelanthran wrote: post #8

Earlier quoted context omitted.

> Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter wh…

Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a…

> Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile.

Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete.

> Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.

To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug.

[1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.

Re: Even with Agile and Scrum waterfall will sneak in

#63

Post by jollybean » Mon, Dec 06, 2021, 11:37 AM UTC

drran wrote: post #16

Flankk wrote: post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.

"Water is a good, predictable process"

No, Waterfall is bad precisely because of the inherent unpredictability of a given project.

Never in all of history was a large software project speced out and built on time.

Software lives in a dynamic environment, so the process has to be mutable.

Maybe the answer is not 'Agile', but it's definitely 'agility'.

If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.

Re: Even with Agile and Scrum waterfall will sneak in

#64

Post by belter » Mon, Dec 06, 2021, 11:37 AM UTC

pjc50 wrote: post #43

belter wrote: post #27

Earlier quoted context omitted.

You can't - Get Certified in Waterfall. - Claim to be a Waterfall Master. - Waterfall Standup sounds like a song.

You absolutely can get certified in various waterfall processes: https://www.amazon.co.uk/Rational-Unified-Process-Reference-... (I can't believe they chose the "when all you have is a hammer everything looks like a nail" cover!)

RUF was never about Waterfall. Instead was the first effort to progress from there

"(Rational) Unified Process vs Waterfall Model"

https://stackoverflow.com/questions/20560514/rational-unifie...

Re: Even with Agile and Scrum waterfall will sneak in

#65

Post by boffinAudio » Mon, Dec 06, 2021, 11:38 AM UTC

CraigJPerry wrote: post #38

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

Royce argued that only in small software systems can you do a little bit of analysis then a little bit of coding then be done with the project. He proposed waterfall as a way to build larger software systems. He argued that these 2 steps were the only direct value steps in developing software - figure out what the problem is then write a little code to solve it - he acknowledged this was the perfect ideal since the t…

Agile has failed the industry precisely because the other steps are NOT BS.

Unfortunately, de-programming Agile-adherents is more work than actually just doing those natural, proper steps.

Re: Even with Agile and Scrum waterfall will sneak in

#66

Post by boffinAudio » Mon, Dec 06, 2021, 11:38 AM UTC

flohofwoe wrote: post #48

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

> .. then the Developer takes in the materials of each of these steps IME this is the main problem, the "Developer" must be heavily involved from step 1 (and work in a close feedback loop with QA). Everything else follows automatically in ever smaller iteration steps. Software development is first and foremost experimental research work, not a factory line. E.g. if a specific software development task feels like bori…

Yes, developers and managers have to be involved in the full workflow. Why is this so hard?

Re: Even with Agile and Scrum waterfall will sneak in

#67

Post by littlecranky67 » Mon, Dec 06, 2021, 11:38 AM UTC

boffinAudio wrote: post #56

littlecranky67 wrote: post #18

Earlier quoted context omitted.

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

>The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. This just indicates a failure to perform a proper Analysis/Speci…

Any analysis of a problem, requires understanding WHAT problem needs solving. The issue in real world is, buisnesses and markets (as well as technology) are changing very fast, and any in-depth analysis done two years ago might not have the same outcome as if done today again. This is a fundamental realization of agile. If you have a problem domain which is not subject to change, waterfall might be the right choice. But you almost never have that. I know it is hard to accept for us devs, often with backgrounds in Math/Physics/CS etc. because the problems we were trained to tackle there are always the same, and the laws of math and physics tend to never change (or change way slower than in modern markets).

Relevant clip perfectly highlighting the problems you have during requirement analysis: https://www.youtube.com/watch?v=BKorP55Aqvg

Re: Even with Agile and Scrum waterfall will sneak in

#68

Post by boffinAudio » Mon, Dec 06, 2021, 11:40 AM UTC

Scarblac wrote: post #46

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

> There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. I've never worked at a place where all these things a…

Developers who fail to take responsibility for the full workflow, fail.

Its not "Agiles" fault, although this is often used to justify the failure.

Developers have got to realize that they are responsible for the full workflow from beginning to end, and only poor/low-quality developers will work to change that natural law - with negative effect.

Re: Even with Agile and Scrum waterfall will sneak in

#69

Post by littlecranky67 » Mon, Dec 06, 2021, 11:40 AM UTC

ankurdhama wrote: post #60

littlecranky67 wrote: post #18

Earlier quoted context omitted.

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

> Almost always, your customer doesn't know what they want - they think they do, but they don't I honestly don't understand this statement. Could you provide an example to elaborate on this point? I have read it at so many places but it sound more like the fashionable thing to say. The "need" have a starting point, may be a very high level problem statement, and then through analysis, back and forth question answerin…

It is very easy actually. We often a business uses Excel for their processes and flow, that is they have excel sheets that they edit, copy, send around and merge back. Now, we all know the problems that exists with this approach, and even the customer knows that. But that doesn't mean they can perfectly describe how any application that gets rid of those excel files should look like.

Re: Even with Agile and Scrum waterfall will sneak in

#70

Post by jollybean » Mon, Dec 06, 2021, 11:40 AM UTC

pydry wrote: post #20

I noticed this as well. No matter how dedicated the team is to not doing waterfall, waterfall nearly always creeps its way back when anything that even smells like a deadline rears its head. Waterfall planning tends to get ramped up for four really common reasons: * Managers who simply cannot conceieve of non waterfall planning. * As a response to failure (ironic coz it tends to increase failure rate) * Because it's…

Waterfall creeps in because it's the most rational and linear way to do anything and we do it in all activities is our life without even thinking about it.

When you build a deck, you 'Waterfall' it.

Iterative development is slightly counter intuitive, until you write software for long enough, then it's definitely the intuitive approach.

I suggest the simplest, easiest, best way to combat the urge to overplan is to break the waterfall down into iterations, do those iterations, assign maybe risk to different iterations given unknowns and to expect change.