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

111–120 of 144 posts

Re: We always end up with waterfall

#111

Post by sjducb »

If you’ve got a release deadline, and a list of features that need to be ready by the deadline then you’ll end up doing waterfall.

If you have flexibility about when features can be released then you can do agile.

I wish the agile and scrum evangelists were honest about this.

The most agile company I ever worked for never talked about scrum or agile. We just asked customers what they wanted and integrated it into the product. When features were ready we released them. There was no roadmap or timetable. Sometimes customers would ask us when things will be ready, we always pushed back on giving dates.

Re: We always end up with waterfall

#112

Post by tstrimple »

oblio wrote: post #92
potatohead00 wrote: post #76

Earlier quoted context omitted.

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

The standard fix for this is to put the devs on call. Recurring operational issues get fixed mighty quickly when J. Dev has to wake up a few times at 02:00 on Saturday. Heck, design and architectural issues suddenly get a lot of scrutiny at the whiteboard phase and people decide they don't really need Kafka or Kubernetes or Mesos or GenAI anymore.

This is why I am a fan of build & run teams instead of having a separate ops org which is responsible for keeping things running. The incentives aren’t aligned and almost always result in silos and excessive outages. The shared responsibility means no one is actually accountable and solvable issues persist for years. Almost every client I work with who has major ops issues have separate teams handling build and run aspects of their projects.

Re: We always end up with waterfall

#113

Post by dalyons »

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…

everywhere I’ve seen it implemented scrumm is not at all the opposite direction - it’s just waterfall with a two week scheduled whipping meeting.

Re: We always end up with waterfall

#114

Post by datadrivenangel »

There is an inherent tension between planning and iteration. As you plan for more and more unknowns, the cost of planning increases towards infinity.

There is an optimal amount of planning, but knowing it exactly in advance is suboptimal in terms of planning planning cost.

Re: We always end up with waterfall

#115

Post by ozim »

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…

I don’t believe there is something a dev is coding right now that will affect current quarter results.

I just don’t see it.

But I see bunch of middle managers who think it will affect their bonus if they push little guys to deliver sooner.

Re: We always end up with waterfall

#116

Post by datadrivenangel »

bratbag wrote: post #42
mrmlz wrote: post #39

Earlier quoted context omitted.

I'm not really sure what you are arguing. Of course if its a one man job (or a couple) and the .. product or whatever isn't system/safety critical even having a PM is probably overkill and the overhead of "any" process likely just wrecks the output. But if you need to organize 50+ engineers and actually produce a ... product? That people/agencies/customers expect things of you sure as shit is going to need a definabl…

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.

Re: We always end up with waterfall

#117

Post by marcosdumay »

doctor_eval wrote: post #60
The_Colonel wrote: post #24

Earlier quoted context omitted.

> But waterfall itself was a straw man I disagree. I've been in many projects which looked exactly like the stereotypical waterfall, with the expected results (delays, death marches).

You misunderstand, the idealised waterfall model was literally presented as a straw man. The horror is that it got picked up as a legitimate SDLC. Hence your exposure to it. It’s almost like they saw the pictures and didn’t read the words.

Yes, the person that invented the name couldn't possibly imagine anybody was stupid enough to practice that thing he described.

At the same time, that process he described was the standard procedure for government and any large corporation contracts.

Re: We always end up with waterfall

#118

Post by tru1ock »

jillesvangurp wrote: post #45

The exception to this is of course open source projects operating at a much larger scale than most software companies. But they have come up with highly structured ways to develop that don't involve planning out everything in detail, which is a waterfall thing to do. Linux project: releases regularly every eight weeks or so. Chrome & Firefox: same thing. In fact most well run larger OSS projects seem to end up using…

How do you decide on whats next? Is this a cost of delay calculation?

Re: We always end up with waterfall

#119

Post by hotsauceror »

oblio wrote: post #92
potatohead00 wrote: post #76

Earlier quoted context omitted.

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

The standard fix for this is to put the devs on call. Recurring operational issues get fixed mighty quickly when J. Dev has to wake up a few times at 02:00 on Saturday. Heck, design and architectural issues suddenly get a lot of scrutiny at the whiteboard phase and people decide they don't really need Kafka or Kubernetes or Mesos or GenAI anymore.

In 15 years of experience here and there, only one has had on-call devs. I’ve come to the conclusion that neither dev nor their management care if someone else’s phone rings at 02:00. I’ve also seen open hostility to 1) the very idea of dev going on-call, and 2) technical recommendations for solutions to recurring issues. So I think it’s not quite “the standard fix”, in fact I think it’s pretty unrealistic.

Re: We always end up with waterfall

#120

Post by datadrivenangel »

hirvi74 wrote: post #93

Perhaps not "true" Agile, but I strongly believe modern, corporate Agile with Scrum with nothing more than a micromanagement framework.

Micromanagement, it's the only way to safely scale agile and ensure you're getting maximum resource utilization.
Post reply on HN