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

81–90 of 144 posts

Re: We always end up with waterfall

#81

Post by baz00 »

No we don't.

Waterfall is probably the only way of managing large quantities of differently skilled people on a software project and actually getting somewhere though.

True agile is for very small teams of highly competent people only, which are rare.

There are some corrupt organisations out there selling process models which tell you you're getting the latter but actually sell you waterfall again with bits renamed. This drives people away who are sold the agile model at an interview because the people who are invested in it in the organisation don't know either process well enough to rationalise it. So people arrive, realise it's a shit show and leave again quickly. That's reality and it sucks.

I think people need to talk more around the social and political structures of organisations that drive the process model rather than two camps because there's infinite varieties of both ways of doing things.

Re: We always end up with waterfall

#82

Post by pc86 »

CharlieDigital wrote: post #79
smugglerFlynn wrote: post #70

Earlier quoted context omitted.

You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning. The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work…

> eventually met That might work in some fields, but consider life sciences and pharma where some unmet functional/compliance issue could be injurious to the company, a patient, or both. Waterfall-ish workflows are hard to avoid in such cases. We learned to simply do iterations of waterfall and speed up the validation via automation as much as possible.

Even if that's true - I'm not sure it is, particularly in very early R&D phases with no external impacts - all that means is that non-waterfall doesn't work absolutely 100% of the time, which nobody is saying it does.

Any time an engineering methodology is discussed, people come out of the woodwork with their specific example of one time where that methodology won't work.

Re: We always end up with waterfall

#83

Post by ferd »

Nitpick: The RUP is not waterfall. First sentence on Wikipedia: "The rational unified process is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003".

Now, it IS very heavy and bureaucratic, and 99% of corporations applied it in the worst way possible, with heavy tooling and in strict waterfall fashion (even IBM/Rational consultants).

Re: We always end up with waterfall

#84

Post by [deleted] »

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…

[deleted]

Re: We always end up with waterfall

#85

Post by BoxFour »

hnben wrote: post #19
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 I don't want to be pedantic, but waterfall does mean exactly that by definition (or at least it used to). There are plenty of variations, that include prototypes or MVPs or iterations (e.g. V-Model, Spiral model). > waterfall is just the straw man of scrum zealots You can't just change the definition of a word, and then call people using the original definition "zealots", see h…

> waterfall does mean exactly that by definition

Hilariously: https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_...

Re: We always end up with waterfall

#86

Post by AnimalMuppet »

SideburnsOfDoom wrote: post #8
JackOfCrows wrote: post #6

For people who worship capitalism as much as folks here do, a lot of you sure don't get business processes. Yes, you wind up having to plan things, because the rest of the business world runs on deadlines and contracts and milestones and deliverables. Agile is, God forbid, almost like being an artist or low, disgusted whisper liberal arts major...when done correctly, in that you're iterating and tinkering and shippin…

The question that you're missing is: Which works better? Which delivers more better software, more reliably? Granted, the business world does run on quarterly results and shareholder value and being able to say ..., but you can say any damn thing that you like, only promising it doesn't guarantee that it will happen. Software development is always uncertain, the question is how best to tame that - ignore it or lean i…

Let's say agile can deliver better software, and maybe even more reliably. The issue is, somewhere up the org chart, there's someone who operates in terms of yearly plans and quarterly results, and there's an impedance mismatch between that layer of the org chart and the agile process below them.

Even if you can really do agile (instead of "Agile"), that mismatch can ruin you. In the long run, it probably will, unless you have someone on the agile side able to talk in terms that the other side can understand. The agile side has to actively manage that connection; the business side isn't going to do it for you.

I have seen the best agile environment I have ever seen destroyed by this mismatch. Upper management killed it because it couldn't understand how to measure and predict the agile development process.

Re: We always end up with waterfall

#87

Post by AnimalMuppet »

potatohead00 wrote: post #76
solatic wrote: post #63

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered. If the organi…

... and leave ops/ devops / are team to pick up the pieces (or put the pieces together) because now your too busy to iterate because your shipping another new thing?

1. If you're agile, you're not too busy to iterate because you're shipping another new thing. You're able to come back and iterate if that's the most valuable thing you can work on.

2. When waterfall delivers the wrong thing because the requirements from two years ago weren't updated to reflect two years of new reality, someone has to pick up the pieces from that, too. It may not be devops - it might be sales instead. But it's still a problem.

Re: We always end up with waterfall

#88

Post by btbuildem »

rstuart4133 wrote: post #17

The Zen of waterfall: At some level everything is waterfall. If anything is to get done at all the programmer has to make a plan, then put his head down, arse up and implement it. At another level nothing is waterfall. If the plan is successful it was shipped to the consumer (which may be the programmer himself), and it's very presence changes things for the consumer in ways that they didn't foresee. They then realis…

If you want to get more abstract with it: waterfall is in two dimensions. The process of starting something and working toward completion can be represented as a waterfall (in 2D) but always and by definition must be represented as a line (in 1D) between two points: start and finish.

If you project from 1D to 2D, that linearity will always be there (for completed projects, at least). That extra dimension will introduce additional flavour, and waterfall seems to be a very frequent one.

Re: We always end up with waterfall

#89

Post by nick_ »

paulsutter wrote: post #61
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…

Discovery vs design is the real dichotomy. When discovery is needed, move in small steps with lots of discussion. When design is possible, move in big steps with detailed specs We’re biased to overestimate our understanding of problems, so we should lean towards discovery mode and small steps Dysfunctional agile has detailed specs and little discussion (no discovery, myopic design)

100%. I'll add that dysfunctional agile can also insist it is discovery, when in fact they just won't hire people capable of design.

Re: We always end up with waterfall

#90

Post by rapnie »

timwaagh wrote: post #29

RUP really isn't waterfall anymore. It's not as linear. It's it's own thing, a sort of hybrid model. The nineties already knew the issue with expecting to get everything right the first time. The problem with it is it's too complicated. Your management with the mental capacity of a five year old just wouldn't understand it.

And RUP had iterations as well, and parallel disciplines. It had a lot of good to the overall idea. Are there modern variants? As a pattern library maybe, take just what you need.

https://web.archive.org/web/20230322153353/https://sceweb.uh...

Post reply on HN