It happens outside government too. It happens anytime your higher-level boss tells you: "Yes, I'm on board! You're right, a system like that would help us tremendously in several ways! Please estimate the costs for it so I can get us the money in our budget meeting next month." Happens all the time in enterprise businesses and the newer methodologies are extremely difficult to use in this sort of situation. In this case, I need some specs up front, create dev estimates, all to ultimately deliver a rough dollar amount or sometimes a "not to exceed" number for my boss...
Waterfall is only mostly dead. I'm told that the reason why the public sector prefers price-and-scope-up-front is that the alternative of "we'll keep delivering things as long as you keep paying us" sounds to them far too much like ways that they have been ripped off badly in the past when buying tanks, bridges, etc.
That is absolutely the reason. On top of that, the only reason they want to use iterations (along with the dreaded inchstone) is so they can use Microsoft Project as a progress bar. If you try to change your iteration deliverables (that were set three years ago) because of actual project issues, you get a ration of shit from the government and their advisors.
Not only are there projects where waterfall methodologies were applied, but they are sometimes (gasp!) appropriate.
In the majority of cases, iterative development of some sort is necessary, because the requirements keep changing. Waterfall simply doesn't allow for changing requirements, so it's hopeless in those cases.
But where requirements are stable, waterfall is a reasonable approach. Remember, it had its origins in the big iron days, when vast project teams analysed and replaced existing manual systems. For those projects, waterfall worked.
If you're writing the code for a space probe, or a missile, there's a limited opportunity to iterate once the item is deployed... requirements are stable, waterfall can be a rational choice.
Don't know about the formalization by Royce, but I've witnessed and suffered waterfall in practice - let's call it ad-hoc waterfall if you will - and it was no urban legend.
And on moonless nights I still wake up screaming remembering a RUP project I was involved in around 2000.
The guilt and shame is so spot on. Living though such projects illustrated so well the "the beatings will continue until morale improves" project management school of thoughts.
This school has its agile proponents too, though. But compared to the common practices of the penultimate decade, XP and Agile at least acknowledged that failure was the default mode of software development projects, and made contingency plans for it.
I was part of a development organization that, driven by guilt and shame, tried to mature and improve their "ad-hoc" processes by fully embracing by-the-book waterfall.
To me it felt like they were saying, "You know all the things you did to make your last project a huge success: the short iterations, tight feedback loops, early and frequent customer involvement, designing your systems to accommodate change? Yeah, don't ever do any of that again."
So I left, and found that dogmatic by-the-book scrum shops can also be horrible places to work. Live and learn.
Absolutely. If the waterfall isn't working, you need to waterfall harder. Because more time spent up front writing paper architectures and guesswork requirements is what's needed!
oh, don't get me wrong i've worked in that environment, but its just a natural naive way of doing things - dignifying it with a name seems to be something that happened later
Some companies did use it. But even at the time (before Beck's book), it was known in programming literature to be a dumb idea. XP didn't introduce the idea that Waterfall was nonsense, it was just the catylist for it's removal.
Bullshit.
Source: I lived through it in the early and mid 1990s.