Hacker News Reader

Comment by kstenerud | Hacker News Reader

Royce's waterfall model is what was actually being used until the mid-2000s in most software houses. And it was one of those processes that looks good on paper, but doesn't actually save you time or effort.

I don't know where this "rigid" model comes from, but I never encountered it in the early days. Everyone knew you couldn't just complete a phase in totality and then move on to the next; there had to be overlap and stepping back up to an earlier phase as you discovered new things.

I suspect the "rigid" variant is merely the hyperbole that waterfall has been reduced to since there are no more proponents of it left. Doesn't make the Royce variant useful, though.

View on HN

It's not strictly an artifact of BigCorp From The Past. Frankly this model is what has been followed in most teams I've been on at Google, well into this part of the 21st century.

PRD -> design doc -> code -> launch -> promotion.

Of course, it's broken down and full of a mess (like a real waterfall) at most stages.

I feel like in a way it was a disservice to my career having a decade and a bit of work in smaller companies (where we often shipped quicker and with a less dysfunctional process) before coming to Google. Because the people around me seem to find the way things are... all quite fine and dandy while I just stare in cynical disaste.

The new team I'm on seems better, though.

you might be attaching too much importance to shipping quickly. being promoted quickly is the metric of importance

It's a model that allows contractors/consultants to declare a phase of the project "complete" and bill for it. And then to bill for change orders/rework after that. It's not about building good software, it's about making money building software.

Let's not forget upfront and arbitrary budget and time constraints from the customer side.

"We want the project to be delivered by X, and we have a budget of Y. Our specs are Z, but not really, so factor in A refactorings (A for arbitrary). Oh, and we don't have Q for Quality defined."

Especially prone in government and military contracts. Throw in some arbitrary public procurement rules so that Y is allegedly not disclosed, except to the select contractors that somehow know what the desired Y is and what the competition is bidding before bid close.

You get the F-35, which pragmatists say was never meant to fly, just to make the players rich in the process of failure.

Sauces: https://www.forbes.com/sites/davidaxe/2021/02/23/the-us-air-... https://pando.com/2015/09/24/war-nerd-why-f-35-albanian-mush...

Until 2010, I only worked in startups, small outfits. So I can't speak for "all software houses".

Speaking with refugees from megacorps, I do have the impression that bigger projects had different people (subteams) doing the different phases, with little overlap. I have no trouble imaging how that'd quickly become a Kafka nightmare.

You'd generally have PMs who had little contact with the engineering team proper. They'd take requirements from the execs, turn them into design documents, and then pass them to the engineering team to implement. So there would be a fair amount of friction, yeah. And lots of DFDs and ERDs that didn't match what was really happening ;-)

But then again nobody on the engineering team took them too seriously anyway, so it kind of worked out.

The main problem in those days was centralization of decision making at the top, where the decision makers had the least exposure to the reality on the ground. The military legacy of computer systems, I suppose...

Ya. I think that's just a very hard problem. Mostly due to scale running up against organizational psychology.

I helped a friend with some property tax software for governments. Trivially technically, almost intractable organizationally. Not for me. I deeply respect the people who can swim those waters.

Reply on news.ycombinator.com