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

121–130 of 144 posts

Re: We always end up with waterfall

#121

Post by datadrivenangel »

ozim wrote: post #115
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.

The software shipped this quarter affects the results next year, and potentially for the rest of the life of the software.

The middle managers definitely win more if they ship more.

Re: We always end up with waterfall

#122

Post by CM30 »

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.

That's kinda how it works at my current job, where a support rota is manned by members of the various development teams (front end dev, backend dev, app dev, platform ops, etc). You can indeed get woken up at 2am on a Saturday, and expected to fix whatever mission critical issue has popped up at that point.

It doesn't seem to have changed much as far as the architecture process goes though. With a few exceptions, the things that pop up for support to handle are usually either 'something broke on the content side, and the editors can't fix it', or a third party broke (glares at Google and Tag Manager, Musk and Twitter/X, etc)

Re: We always end up with waterfall

#123

Post by cynusx »

You know, waterfall only fails when you build things nobody wants.

If you, on the contrary, invest ridiculous amounts of time in user research and only build things that are validated then waterfall is fine.

Re: We always end up with waterfall

#124

Post by esafak »

tcmb wrote: post #10

"The Internet brought agile, what will remote work bring?" Interesting question. What are the companies doing that have been working remotely already years before the pandemic? How is e.g. Gitlab working? Would love to hear people's experience. It's not like Agile cannot work with remote collaboration, just that waterfall is more suitable if people have a tendency to isolate and form silos.

Initially it will bring more asynchronicity. More writing and recording. Later it might involve more XR.

Re: We always end up with waterfall

#125

Post by esafak »

28304283409234 wrote: post #22

Agile always was the answer to that nagging project manager asking “When will it be done?” By engaging with an answer the engineers kept being part of the discussion. Instead, they should have said: you don’t get to ask that question. That question has no place here. Engage with us in building the product and let us create and enjoy! Of course, the real world needs deadlines, timelines, roadmaps. And thus, agile is p…

Managers should be predicting and controlling the delivery time by clearing organizational roadblocks and shaping the work to be done, not how it is done.

Re: We always end up with waterfall

#126

Post by loa_in_ »

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…

Assuming a team of all at least proficient developers, one who's living a peaceful life outside of work is going to be put into the first category, and people with more chaos in their lives (not by their choice) will fall into the latter category. As their life situation changes they have a bigger chance to lose context, forget who's who or miss out on word of mouth; or conversely, become a sponge for company culture and leave the office with energy for fulfilling projects outside of work and get involved with, for example, open source where they gain insight that they take into work later, for example perspectives on business specific knowledge or some analogues.

Re: We always end up with waterfall

#128

Post by jillesvangurp »

tru1ock wrote: post #118
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?

Factors into it. Im a big fan of Don Reinertsen as well. But in a small team what matters is the big picture.

Re: We always end up with waterfall

#129

Post by nophunphil »

loa_in_ wrote: post #126
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…

Assuming a team of all at least proficient developers, one who's living a peaceful life outside of work is going to be put into the first category, and people with more chaos in their lives (not by their choice) will fall into the latter category. As their life situation changes they have a bigger chance to lose context, forget who's who or miss out on word of mouth; or conversely, become a sponge for company culture…

I think some developers are just not proficient though. You make a fair point about life circumstances, but not everyone can be prescribed to this track.

Re: We always end up with waterfall

#130

Post by yafbum »

loa_in_ wrote: post #126
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…

Assuming a team of all at least proficient developers, one who's living a peaceful life outside of work is going to be put into the first category, and people with more chaos in their lives (not by their choice) will fall into the latter category. As their life situation changes they have a bigger chance to lose context, forget who's who or miss out on word of mouth; or conversely, become a sponge for company culture…

Also it's a matter of skill fit. To take extremes I worked with engineers experienced in mobile app game engineering, who were thinking about UI latency in obsessive detail, and engineers skilled in thinking about ML ranking problems, who had deep knowledge about the strengths and weaknesses of various ML approaches. You could've swapped their roles and it would've been a disaster, not because they're not proficient, but because it would've taken a long time to ramp up on what's important in the other's area
Post reply on HN