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

131–140 of 144 posts

Re: We always end up with waterfall

#131

Post by marcus_holmes »

The_Colonel wrote: post #33
marcus_holmes wrote: post #15

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever. The product is developed using waterfall and then it gets put in front of a stakeholder, who has changed their mind in the time between the initial spec and the delivery. So another, smaller, waterfall is created. This is iterative development. And it always happens, because no-one gets product deve…

I think this ignores two major constraints - the "waterfall mindset" was about stakeholders (customers) believing they can get a finished product in a fixed timeline for a fixed price. What happened then was that after the delivery, the stakeholder was wildly unhappy with the result and demanded re-work, but that would be unplanned and un-budgeted. Many ugly arguments and finger pointing would ensue, which could repe…

This is what I mean. Everyone does iterative, it's just that a lot of people don't realise it's iterative so do it badly.

Re: We always end up with waterfall

#132

Post by mycall »

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…

This is known as iterative waterfall.

Re: We always end up with waterfall

#133

Post by AndrewKemendo »

My favorite part about being in software over the last 20 years is watching software engineers reinvent all of the processes that every other engineering discipline has been utilizing for tens if not hundreds of years from first principles.

I suppose it makes sense given how young SWE is, but I think the fact that cybernetics died and computer science was treated more like mathematics than engineering, so software people rarely if ever practice system thinking.

It’s also striking that a software engineering undergraduate will never take a course on ethics, or social theory, as part of a core engineering curriculum. Whereas within the mechanical and specifically civil engineering, you will absolutely take courses that show you your social impact on your engineering.

That is just never happening in software pedagogy

Re: We always end up with waterfall

#134

Post by thoughtpalette »

yafbum wrote: post #102

No amount methodology is going to make gold come out of a team that doesn't deeply understand the reasons for building what they're building. I work with a small-a agile team, and the devs who "get it" just make it happen without a waterfall. The ones who don't get it get a super detailed spec to minimize the chances they'll mess it up, and still mess it up. The ones in the middle know when to reach out to ask for an…

I think this pretty much sums it up.

If you have a skilled team with deep domain knowledge, you can afford to not be as detailed in the planning process as the team is most likely already aligned.

If you have a skilled team without deep domain knowledge, you need that sense of unity and alignment, that usually comes through more detailed planning.

It's not one's correct or one's wrong, it just depends on the team composition.

Re: We always end up with waterfall

#136

Post by ilrwbwrkhv »

nicbou wrote: post #67
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…

The problem is that some things must be perfect, because they expose the company to significant risk. You can iterate on a feature but not on compliance.

You can iterate on compliance too. Just ask Uber.

Re: We always end up with waterfall

#137

Post by Earw0rm »

switch007 wrote: post #30
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…

Huh? I’ve never seen scrum fully implemented. It’s always been pick and choose. The most common defence from Certified Scrum Masters TM © is that you haven’t implemented it correctly/fully. Does YMMV?

Am reminded of similar defences used for Marxist communism. "Oh, it only devolved into totalitarian misery every single time they tried it because they forgot to xyz".

Re: We always end up with waterfall

#138

Post by psunavy03 »

datadrivenangel wrote: post #116
bratbag wrote: post #42

Earlier quoted context omitted.

Good luck building a chronology for 50+ engineers ahead of time that isn't either horrifically over estimated or instantly wrong. Waterfall is a pacifier for people who would rather have lies than uncertainty.

>Waterfall is a pacifier for people who would rather have lies than uncertainty. This is the truth. It's painful to see, but some people would prefer to light millions of dollars on fire than admit they don't know.

It's not just about "admitting they don't know." It's about giving up the control that they've used to define their entire professional lives as "managers." Thank you Frederick Winslow Taylor for your outdated ideas.

Re: We always end up with waterfall

#139

Post by psunavy03 »

ferd wrote: post #83

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).

Sort of like SAFe, which . . . oh, wait! Was developed by the exact same people once they decided to get on the Agile gravy train!

And I say that as someone who works in Agile, supports it 100%, and has no time for the "it's a scam" whining.

Re: We always end up with waterfall

#140

Post by rramadass »

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…

> but waterfall does mean exactly that by definition

No.

This article The Myth of the 'Waterfall' SDLC gives you the details (archive version since the site seems to be down) - https://archive.is/jbBta

Post reply on HN