Live data from Hacker News

We always end up with waterfall

amazingcto.com

141–144 of 144 posts

Re: We always end up with waterfall

#141
post #92

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 thinking is one reason why I left engineering and I don’t see myself coming back to it anytime soon. I don’t like being on-call, I’m not qualified to do Ops-like decisions and I haven’t seen this as the practice in most other industries - Boeing doesn’t have staff flying planes for the airlines, for one.

Compliance is a set of stories/tickets/requirements like any other, with a priority to be assigned and eventually worked and reworked at some point in the process. There’s nothing wrong with not addressing it as the first thing - it just blocks release. With that, it will eventually get worked on, hopefully at the time where the pieces that need it are understood and the work to reach it is understood.

Re: We always end up with waterfall

#142
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…

> nobody advocates for balance and nuance. Some people do, but they don't get the views or the support. People are gregarious, they want to be part of a team, middle ground is not a team, unless you create a new name for it. People tend to give support to whoever hates what they hate, not to those who love what they love. So the middle team shouldn't be sold as "the good parts of A and B" but as "we hate A and B". Fo…

> So yeah, that's why there are so many ways to do projects: waterfall, agile, scrum, kanban, scrumban, XP, ... .

Bit of a weird mixing of levels there: Everything you mention after "agile" is (more or less) "agile".

Re: We always end up with waterfall

#143
post #36

Earlier quoted context omitted.

Yeah - I mean, when I wrote the comment I ignored all the absolute disaster-projects I've seen. But those where doomed on so many levels I don't even wanna blame waterfall or agile or the in-betweens.

So, "if you ignore the ones without iterations, I've never seen a waterfall model implemented without iterations."

We can't be sure there wouldn't have been any iterations. In (what's traditionally been called) the waterfall model, there's so long between iterations that the project has time to fail and be scrapped before there ever is one.

Re: We always end up with waterfall

#144
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…

> scrum is too much Surely scrum is too little? Most lowercase-a agile people consider it more of a stepping stone into agile.

Depends what you mean. Too much flexibility, true agility? No. Too much process, ceremony, empty ritual? Oh yeah.

And no, AIUI most original-ideals-agilists consider (much or most of) Scrum a stepping stone away from "agile".

Post reply on HN