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

101–110 of 144 posts

Re: We always end up with waterfall

#101

Post by sanderjd »

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…

I think this is totally right. But some things really do need to be as close to perfect as you can get them. The things in that category that I've run into most are security, privacy, and legal compliance. But in other applications, safety issues would also go in this bucket.

So those things really do need a proactive gate, or maybe in some cases, at least an extremely fast reactive response capability.

But this just means it is more important to identify the smallest set of considerations like this, in order to give them special treatment, rather than requiring higher scrutiny for everything - if everything is special nothing is special - and to invest in ways for work to be done without implicating those special considerations.

Re: We always end up with waterfall

#102

Post by yafbum »

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 out-of-cycle product clarification before building a useless pile of code.

The main difference is, do they understand why they're building what they're building? Or do they show up, punch through a bunch of tickets, go home? Really hard to fix that with process when that's not working. It starts with good hiring, building a vision together for what we're building, and communicating it repeatedly.

Re: We always end up with waterfall

#104

Post by JohnFen »

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…

> Getting rid of Waterfall is learning to let go and to live with imperfection.

To a degree. But I'm pretty sure one of the reasons why software quality is so much lower these days is because many teams take the idea too far.

Re: We always end up with waterfall

#105

Post by JohnFen »

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.

If anyone is getting 2am calls more than extremely rarely, the process is already seriously broken.

Re: We always end up with waterfall

#106

Post by [deleted] »

kibibu wrote: post #50
SideburnsOfDoom wrote: post #12

Earlier quoted context omitted.

> Honestly I've never seen a waterfall model implemented without iterations. I have. It didn't reach the end.

People should read Royce's paper that popularised Waterfall. It has iterations, sadly it appears most people stopped reading after Figure 2. https://www.praxisframework.org/files/royce1970.pdf

[deleted]

Re: We always end up with waterfall

#107

Post by JohnFen »

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

Honestly I've never seen a waterfall model implemented without iterations. And you can always update the top-spec at later date if needed its just more difficult.. Which it should be.

This. When agile folk talk about waterfall, they're describing something that I've never seen in practice, even from far before "agile" was a thing.

Re: We always end up with waterfall

#108

Post by phillipcarter »

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.

At a $LASTJOB all the devs had to be on call for some services and literally nothing improved. Still haphazardly throwing code into production, poor monitoring tools, and no time or desire to make stuff better. On-call was just seen as shitwork and devs would find other teams that didn't have on-call to transfer to.

Re: We always end up with waterfall

#109

Post by Jtsummers »

Blaiz0r wrote: post #56
doctor_eval wrote: post #21

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

Winston Royce actually did have an iterative process as part of Waterfall, it was in his final model, and the diagram was on the next page of the document that most people fail to recognise. https://upload.wikimedia.org/wikipedia/commons/d/de/1970_Roy...

Royce's model wasn't Waterfall. Waterfall is the model he started with, knocked, and then improved on. Idiots in DoD (and from there industry) mistook his first figure as the target, and not the thing to avoid. They codified it in a standard and it has been the cause of much government and government contractor waste ever since.

Re: We always end up with waterfall

#110

Post by CharlieDigital »

pc86 wrote: post #82
CharlieDigital wrote: post #79

Earlier quoted context omitted.

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

I worked in the pharma space building document management systems that supported clinical and pre-clinical processes (mostly clinical, some R&D).

After a while, one starts to understand the need for the rigor. If some cluster of patients suffers some injurious adverse effect pre- or post-market, the FDA and a bunch of lawyers wants to trace the history of development to understand how to assign responsibility. Software systems in this space are validated quite rigorously against their functional and technical design specifications to verify that the records produced are traceable.

Software validation in this space works kind of like GPL licenses: the sponsor (like a Merck or a Pfizer) is responsible for validating software from vendors when it is supporting a GxP process. Those vendors are then responsible for validating not only their systems, but all dependent systems as well. (A lot of it is risk-based and obviously a lot of the methodology, guidance, and interpretation has evolved since the cloud era. But we used to have to take our customers on tours of our data center and their auditors would match the specifications of the hardware!)

I think it's one of the reasons why -- despite this process being extremely high in "schlep" -- there are few startups in this space because the barrier to entry is quite high. Even having 15 years of domain experience and running a team delivering production systems used by pharmas to run their trials, I don't think I'd want to do a startup in this space.

There's a really great HN thread on this that resonated with my experience that I bookmarked a while back: https://news.ycombinator.com/item?id=33545209

Post reply on HN