Waterfall might have been a straw man but SADT and other structured design principles put an unbelievable amount of dependency on diagrammatic and black box formalised boundaries of flow. All done up front.
People mocked things and prototyped things but I sat beside people who worked for 2 years or more on wall sized collections of ring binders of requirements specifications and flow charts, to end in acrimonious lawsuits.
I do kind of hate agile language. It's smug. But I love rapid prototypes and sprints.
In my field (troubleshooting for enterprises), I encounter, literally every day, prototypes (rapidly thrown together things that 'work-ish') in production and spewing bugs. I wonder where these companies are that actually toss the prototype and do it proper afterwards. Never seen it live, only on paper.
I've done many, many Proofs of Concept that were thrown out after exploration to make way for properly written production code. It's part of any new greenfield project I work at, we do a rapid prototype to validate some early design, learn from it and throw it out.
My field is not enterprises though, I worked all of my 20+ years career at tech companies of different sizes (from startups to 10k+ people orgs), startups and smaller companies usually will throw a PoC into production, and call it "tech debt" for later, larger orgs tend to avoid that since they've been previously burnt by the maintenance burden of poorly designed code in production (usually on their startup-ish phase).
OTOH, I've been in that situation too, and it was successful. The International Space Station has not yet fallen out of the sky. There are situations where waterfall is appropriate.
I am curious if this is usually argued. I thought it that was generally held that agile and similar methodologies at least in the sense that sprints are defined in days/weeks and not months/years is for use cases where the product doesn't have well defined specifications.
And yet the ISS has still had many bits added on, replaced, upgraded and modified. They just work to far, far higher standards than almost any company will pay for because they know if it goes wrong some very high profile people get dead.
"Every time I read about the Waterfall Model, I think to myself: I'm sure there must be companies out there that have tried this approach, but I have a hard time believing some software book would seriously propose it as the best way to write software"
I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified, with the whole design- and implementation phase based on this, with milestones where each step of the waterfall would be delivered and checked by the customer. This was particularly prevalent back in the eighties and beginning of the nineties. It's as real as can be, it did exist.
Obviously developers couldn't follow that 100%, so there would be some amount of back-designing an earlier stage, but if it wasn't 100% it was very close in practice too.
Having worked waterfall and now agile, I miss waterfall. Agile feels too fast and loose. We work faster but we also redo a lot of things. It's an illusion of progress.
What you describe is from micro-managent of the development process. I have never met anyone qualified to micro-manage a software project, and never will.
it works the same if you apply it to other disciplines. The saying, "a plan is useless, but planning is invaluable". Agile just skips the second part by trying to throw out the first part.
I think a real criticism of Agile would be that it works great assuming a) domain expertise and b) good understanding of how accurate / precise a solution has to be to work.
Agile seems to work best when the domain itself is technology, rather than, say, when the domain is HVAC control or real-time ECMs.
Oh, I always think the opposite. If the outcome is technical, then quit playing, RTF specs, design and build it. If the outcome is some wobbly user expectation, wobble back with Agile.
there's probably a rational category based on the size/complexity of the data model. I get the sense that very complicated data models are what really ruins the agile approach for complex environments.
How much do you think it was an artifact of the time? Agile relies on it being fast/cheap/easy to ship and deploy incremental changes. I have a hard time believing that to be the case in the 80s. When planning and designing on paper is cheap in comparison, it makes sense to me that is the development method people used.
I think it was more about the corporate culture which dictated that people had a plan and stick to it.
It's still the case in many trades. You don't build a house or a bridge the Agile way for instance.
IMHO Agile got a lot more prevalent because the planning phase became more and more onerous to have any reliability, and management was tired of paying upfront for it. I steady they could get a more regular billing (in particular when dealing with consulting companies) with reports of stuff allegedly shipped, instead of six months of "we're planning very hard, just trust us". Whether the end result matched what they needed/wanted to build being another story.
I know many companies that had an official Waterfall cycle, while actually working on something more granularly shipped with many phases of prototyping. And they didn't move to Agile either, just stopped calling their process anything and went on doing whatever felt right.
I find agile passive aggressive because the consensus is built under duress. I prefer a well reasoned approach. I can understand agile process in between waterfall milestones.
I can even support an agile process to create waterfall process.
Developers are still constrained by process, and it's their fault.
In every single company I have worked, the process always took priority. It's made even worse where you have ISO 9001 compliance where every god damn thing in the company is locked into a "process." Process over people, period. Coporo-managers can't get it out of their head.
When all you have ever done is "the process" it looks perfectly sane. To teams that can produce a POC and basically get to market on their own domain knowledge, it looks ridiculous. Making developers wait for requirements instead of inventing them on the fly is incredibly slow and smothers nearly all innovation.
Why risk making your product look like your convoluted communication and political structures? The entire point of agile was lost on the influx of bodies to the industry.
Form a "skunk works" team and shield them. Make a big show of how their success came despite having zero fucking process. Jira is for maintenance.
That's why it's your fault, because you won't make decisions. You feel like there are rules and guardrails constraining you and bringing order to society but it is not so. If you envision the reality and live it, then it will manifest. Some people thinks this means being forceful and demanding. Just the opposite.
Then again, I doubt the company has a reward structure in place that even makes the mental energy worth expending.
If you aren't on the way up, then you are on the way out.
> In every single company I have worked, the process always took priority.
If process (or freedom from process) is important to you, you need to make it a priority when you're interviewing. May depend on what industry you work in, of course, some industries don't have any cowboys.
That said, I like my cowboy jobs with a little bit of process. What's deployed in production should be reflected in source control, but I'm not a stickler for which comes first. A change notification should be posted before production is changed, but if you have separate push and load steps, you can push before you notify (if pushing takes a while, it's good pipelining to use the push time to compose your change notice). Changelogs usually shouldn't be 'bugfixes' or 'latest', but 'fixing' is appropriate for a close in time followup. That's process, even if an ISO compliance officer would lose their mind.
At that time the waterfall model method was one solution to the problem of software quality. Other methods hadn't yet been developed (or at least not become well known yet), and waterfall was in use by the industry (not everywhere though - re sibling comment). The customer I mentioned was huge and lots of companies in lots of European countries, and overseas too had development contracts which demanded this process to be used. And the results were actually good, even though the process was heavy. That didn't mean that it couldn't be improved on, and that did happen later, with more agile-like (though not "Agile") methods modifying the approach.
> How much do you think it was an artifact of the time?
I was a software engineer in the 90s at a small company (15 people) doing simulation development for the UK Ministry of Defence. We had two distinct software development processes, which were waterfall and a form of rapid development known as the Dynamic Software Development Method (DSDM). (I threw away the manuals years ago so can’t give more info).
The company directors came from an aerospace background so had a very strong software quality focus. Many of our contracts specified waterfall and our project artefacts reflected that – user requirements docs, system requirements, architectural design, detailed design, integration test plans, system tests, acceptance tests, etc etc. Coding happened somewhere in the middle. It did work, sort of, in situations where the customers knew what they wanted, and we mutually understood it. Which was quite often the case, for our regular customers on projects that were extending existing systems.
We trialled DSDM for projects where the customer said ‘prototype’ and I liked it. It lacked the onerous agile / scrum boilerplate and IIRC was based around loosely specified timeboxes and relied on having ‘intelligent customers’ who were prepared to be flexible in terms of what they got at the end.
The need for DSDM was motivated by a project that failed badly (not with the MOD) because the customers said ‘here are our requirements for this prototype system, don’t come back until you have finished and tested it’. Needless to say the result wasn’t what they expected, even though all of the requirements had been, on paper, met.
But for any development where specific technical outcomes were necessary (e.g. a maths module), waterfall would usually be used.
I got a course at Oracle on DSDM RAD (rapid application development) and worked on a project with it. The 4GL tooling used at Oracle were no good fit, but back then also Oracle was moving up to 3GL tools like JDeveloper. And they thought using RAD was good fit.
Key what I remember was time boxing. And much less religious stance than Agile. But back then it was normal to have different people doing functional designs, technical designs, database design (also in two levels) and business process design of sorts. I guess it took a while for these people to realise they had to be Agile digital transformers.
And I guess it also did not help the DSDM also certified people on the waterfall methodology.
I think it was an artifact of applying physical construction project concepts to building software.
If you're building a house, or something bigger, you don't just start nailing lumber together. You have a blueprint. Pretty detailed, and it uses industry-standard terms and markup. Any builder can take it and use it to construct the building. It has the dimensions and specifications for the foundation and all the rooms. It has considered where the rooms are, which walls are load bearing, where the staircases and HVAC and plumbing and electrical runs are, where the windows and doors are, pretty much everything. An engineer has signed off on the overall design as being safe and meeting all the applicable codes. You can order a list of supplies based on this plan and you'll be within a few percent of what you actually use.
Some small changes were allowed. You could change finish details like what style of cabinets or trim or door knobs would be used. But you could not really approach the builder once the framing was complete and say actually I wanted the living room over there and the bedrooms over here and also I want to add a third storey. You also didn't build one bedroom, and then based on that experience extrapolate the design for the next one, and then apply that to building the kitchen, and so on. It was all done up front.
People, especially people who were used to managing physical projects, thought that with the same level of planning, and the same approach to management, the same results could be achieved in software projects.
> I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified
On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common.
I have certainly seen projects that started by planning everything out. High level designs, milestones, integration dates. Giant GANNT charts. But by the second quarter everyone was pretty much just redrawing the whole map, getting what they could running as early as possible and throwing things off the bus.
If you consider this not as a binary choice, but "waterfall" on one end meaning that the whole design process has basically no feedback, and "agile manifesto agile" (not scrum or any other calcification of the process, but the true chaotic "just depend on your engineers to be smart" process), it's probably true there has never been a "true", all-the-way-to-one-end Waterfall design that went for multiple years, because such a thing is essentially impossible.
It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan.
I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation.
And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
> And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
You captured so much in this one sentence, especially the end, about how waterfall failed the developer, rather than the developer having failed waterfall.
This script-flip works on many other systematized orthodoxies, I suspect.
> I don't consider it a "strawman" so much as a "simplification"
I consider it a straw man because, as the agile crowd describes it, there appears to be no such thing as "waterfall". Perhaps that is the result of comical oversimplification rather than a conscious attempt at deception (I believe this is the case), but it still results in standing up a straw man so it can be knocked down.
If a process is 98% waterfall and management blames developers for the 2% and considers it a problem to be solved rather than something to be harnessed, it's close enough to waterfall for all practical purposes. I don't believe there's a sudden transition in the cost/benefits for waterfall at 100%, in either direction. (Just as I don't believe it for Scrum.) The criticisms will apply.
And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines
If the software industry had the equivalent of "general contractors" who pour the concrete, wire the rebar, dig and fill the holes, install the electrical and duct, laid the bricks, all to within the tolerances specified; AND had architects who knew both the tools available and the domain inside and out, a model mirroring the real estate industry MIGHT BE doable. But there are a lot of differences beyond just the "engineering" aspects (and often times, the head engineer on a project is not the architect).
It's not really binary or a spectrum. Royce was not taking about what he observed people doing, but how he believed large software projects should be conducted in the future.
In that, he first introduces what has come to be known as Waterfall. While he considered it to be fundamentally sound, he posits that it carries significant risk and then goes on to tell what needs to be added to diminish the risk. Those additions are what oft get called Agile (although not in the Manifesto sense).
You have a point that "simplification" is more in line with the device he was trying to use, but with the intent of leading you into understanding the more complex aspects of his idea. Kind of like that owl drawing meme where you start with two circles and then draw the rest of the owl. There is only one idea present. In other words, "Waterfall" and "Agile" are the exact same thing, just at different stages of communication.
Where others have tried to invent "Waterfall" as it own distinct thing to contrast with "Agile", it would be fair to characterize that as a strawman. If anything all projects are "Agile" at their core, with varying degrees of deviation happening in a multi-dimensional space.
> On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common
In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall.
Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement.
You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.
This entire discussion or dichotomy is just a massive and sad misdirection. Its explicitly cargo-culting. In what other world do we spend half of our time talking about and conforming to various 'methodologies'. If we just find the right sprint cadence. If we just do retros better. Maybe some kanban-scrum hybrid. If we just _reallly_ limit standups to 15 minutes. If we clap three times at the end instead of two - then perhaps we will be able to deliver software.
There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.
> In what other world do we spend half of our time talking about and conforming to various 'methodologies
Remember that this is largely about consultants selling advice to executives. This is not about getting stuff done.
BUT software is also a young industry. We just don’t know yet the right way to do it so we discuss and share what’s worked for us. Just like it took a while to find the right manufacturing processes in other industries.
That's because the "right way" needs to vary depending on what you're building. You don't build a garden shed the same way you build a skyscraper. Likewise, you don't build a twitter client the same way you build an implantable pacemaker.
And for that matter you don’t build a twitter client the same way you built a backend for twitter clients to connect to. In my experience every team and project has a unique way of working and that could be encouraged.
Neither have I. Most of my software career has been spent in medical device development: a tightly regulated industry, and waterfall is just a concept.
Sure, you do requirements elicitation, review and documentation, and then architectural design, followed by detailed design & coding, etc. But it's never a linear process end-to-end. There's always feedback. There's always something you didn't account for showing up and requiring a change to an earlier part of the process.
Waterfall can, and does work, but only on fairly small projects that can be completely defined correctly the first time around. And like everything else, it's easier if you've done that kind of project before.
The requirements and design phases can/did often work very well. It's what comes after that derails the process.
When you spend more time trying to update your design to match the implementation (via change requests) than implementing you start to wonder if there's maybe a better way..
I think waterfall and waterfall-ish development is more prevalent in government contracting. You aren't building for yourself, you're building for a single external customer, and you have to build both the functionality and the interfaces that they want.
And I note that government contracting was probably a bigger fraction of all software engineering in the 1980s than it is today. (Still more in the 1960s.)
So, yes, it was real. It is mercifully less prevalent than it was.
Same here. Just 10 years ago I had the displeasure of working on such a project. Months and months of upfront specification work. The UX was defined in full separately from the UI. All the DB models built in one go. Every Gantt cascade one could imagine. Horizontal slice by horizontal slice. The system was to be fully integrated at the very end, followed by a few weeks of QA.
If anyone doubts that waterfall was the dominant approach to development and project management, just go back to the tools of the times, like Microsoft Project. Gantt charts were the unquestioned way you managed a project.
It was definitely the dominant conceptual approach, but I think it's an open question how much it was actually followed versus just being the lies everybody agreed to tell the executive caste.
One way I've weaned people off waterfall approaches is just to tell them yes, of course that's what we're doing, but to make it extra safe, we'll produce software early and often so you can see progress. Then eventually I'll slip in getting users to try it, just for "testing". And then getting it deployed early, for more "testing". The smart ones get engaged in this process, using it to making things better than the initial conceptions. They may produce waterfall documents for a while, especially if they need to pacify higher ups. But often they'll just forget. I think them GANTT charts and the like were always a ritual to get them feelings of control, and they stop doing that work once they have actual control.
So I suspect a lot of the nominal waterfall projects of yore were similarly made to work by developers just doing the right thing in quiet ways while saying, "Oh, that's 90% complete for sure. Mark it on your chart!"
Something similar happened to flow charts. They get unreadable after a few tens of LOC, but the managers required them. So people dutifully shipped tons of paper upstairs, and nobody ever read them. Then they were drawn after the source was written, instead of before. Then a computer program generated them straight from the source code. Then they stopped printing them, storing them on disk instead. Then the flow chart generator broke, and nobody noticed the write-only documentation was missing. Finally, some manager got the genius idea to speed up the process by not requiring flow charts anymore.
This kinda reminds me of a middle school English teacher I had who insisted on receiving both a rough draft and (a couple days later) a final draft, which had to be different, because there had to be at least some grammar/spelling mistakes in the first draft.
I was a kid who didn't make grammar/spelling mistakes. I'd just write up the paper, insert two or three errors, submit it, and then a couple days later submit the original version.
Hmm, here as well. But then would reorganize the sentences, and add details, where I think the most value of another draft is. Fixing spelling mistakes never entered my mind.
>It was definitely the dominant conceptual approach, but I think it's an open question how much it was actually followed versus just being the lies everybody agreed to tell the executive caste.
Its funny because that would the inverse of the current situation where exec proclaims their company is agile to external observers and potential hires, but the de facto regime could be anything
Great point. And in those faux-Agile environments, you'll definitely sometimes find people just doing the right thing and then finding the right way to lie to JIRA about it.
One company I worked with we switch over from waterfall to agile. The 'guardian' of the rooms of paperwork was so happy when she could bin 2 rooms full of filing cabinets overflowing with designs no one really followed. Took her about a week to clear it all out. Hundreds of rolls of gantt charts dumped into a recycle dumpster. Basically we stopped pretending we were not redesigning everything as we went along.
I worked professionally from the late 90s. We used Gantt, but it was always for spiral or unified process. We were always told to avoid waterfall (as there’s a natural tendency to go that way) and always include feedback loops.
There's a reason why construction and other projects that require coordinating with external parties rely on Microsoft project so much.
I'm on a project now trying to manage external customer cutovers and integrations using JIRA and its a dumpster fire.
A proper project plan with deadlines, lead times, resources etc would solve 99% of the problems.
Its just non stop crisis "oh we forgot to get get change submitted on time" - "oh this customer can't migrate until date x" - "oh this test environment is down for scheduled rebuild on days xyz" - all can easily be tracked to automatically calculate timelines.
Agile is fine at a macro level, but it needs to feed into a better system for real world dependencies and deadlines.
> with milestones where each step of the waterfall would be delivered and checked by the customer
I think this is one of the things that don't explicitly follow the waterfall diagram as presented and criticized though. You're delivering smaller units of work here and I presume incorporating their feed back at least to the extent of if it is functionally meeting the specified requirements which is kind of agile-y.
The main difference between the two at that point seems to come down mostly to the willingness to revisit the requirements which even when my employer was more waterfall we would try to incorporate changes if the customer came back and said what we were doing wasn't going to work at all or they needed changes.
Nope, in waterfall, "deliverables" might mean things like "UI design" (as a slide deck) or "database schemas" (on paper, without data) or "this microservice" (in isolation, and which you cannot run because dependencies and consumers are not implemented yet)
If you are producing anything a customer might actually before the very end of the project, it's not waterfall.
That's what the article is saying in part. Very few people showed or tested absolutely nothing before the very end of the project so if that's a requirement to be 'waterfall' it was a strawman that's easy to argue against.
Of course there's a range of transitional states between waterfall and [whatever miracle cure is in vogue today]. Like all historical revisionists, today's techies like to impugn the old and laud the new. ('How could they have been so clueless?')
Fact is, long-lived products, esp. from BigCorps, and esp. those in heavily regulated spaces like medicine and transportation always have and always will spend a lot more time and effort on design and process than will ephemeral products and services from startups. My software career started ca. 1990 just as waterfall was evolving into the 'Spiral' iterative software model, which since has been rebadged and remorphed several times into today's 'agile' and 'test-driven' gift from god. However in the real world, makers of every S/W product inevitably must adapt their actual development process to suit the lifecycle needs of their product and customer, in ways that scrum can't serve. Often the best way to reduce technical debt is to increase investment design and testing. And taken to NASA-like limits of fault-tolerance and reliability, that can take you all the way back to waterfall.
We use extreme waterfall. All the disadvantages of agile and waterfall in one process. Nothing gets to production due to meetings so the customers are happy we aren’t fucking anything up.
The whole strawman/dichotomy you see with Agile and Waterfall boils down to needing both flexibility and vision for large projects, and each fails at one of these.
So like a waterfall, but the day to day is connected by little bits of agile? You end up at the bottom of the waterfall, but by taking a bunch of much smaller falls instead?
Have you considered calling it Rapids development? You will sell a million books or whatever, just on the name.
This. Some products are platforms with thousands of functionalities all interlinked in a uniform data model, with similar but specific behavior expected for all modules of the platform.For instance, a Core Banking System, or OMS in Telcos. And since we all get paychecks, it seems to work.
Building such an product in agile was often tried and failed in the past decade. You need common data structures and routines that a few thousand developers can all expect to find ready further down the line. Like the Oregon Trail game, you launch all workstreams in different moments and expect them to converge at the finish line.
I think “100% waterfall” was ditched in the early 90s, for all the known reasons, with smaller cycles of releases becoming the norm. But still the hard thinking, laying down the key mechanisms of a platform was heavily thought out early on.
I think all criticism is a bit unfair, as agile is also an infinite source of cock ups, mediocrity and dead ends just as waterfall. There is a space for each approach, and bottom line, the right people will make all the difference. But that’s also why it’s important to learn and respect both approaches…
Indeed. Every real-world practice of development can be placed somewhere on the sliding-scale between Waterfall and Agile.
One of the reasons that waterfall was a reasonable way to proceed was that, in the past, tighter coupling to hardware and longer hardware lead times meant the need to design and specify in advance. This is still somewhat the case where these conditions are true, albeit to a lesser degree.
Yeah, I think the Waterfall model is what naive non-experts want from a project. I say what I want, you build it, it's delivered on time and on budget, and we're done.
But I think it's basically a fairy tale. "And they lived happily ever after" for executives. And I can prove it. There are basically no successful products that started with an executive idea, were created in a waterfall fashion, and then stayed at that initial version forever. Waterfall is built on the fantasy of managerial omniscience, where the people in charge know everything important on day 1. But the reality is that the beginning of a project is when we know the least. Waterfall in practice is a bet nobody will learn anything as time goes on. And on waterfall projects, that often turns out to be true, if only because course corrections would cause executives to lose face.
I too worked on waterfall dev projects. It was a nightmare and did not ship. The Agile Manifesto was a breath of fresh air, just because it captured what a lot of people were thinking in a way that was coherent enough to present to managers as a viable alternative.
I joined a company that had adopted "agile" (in reality scrum + 2 week sprints) after a dramatic waterfall failure. They had attempted to rewrite a good, working, profitable product and had spent 2 years on the designs, only to throw it away because they just couldn't get it completed.
On scrum projects I've been on, its essentially the waterfall model. Business comes up with a product and date, product and engineer give high level estimates. Program manager creates a project with all the stakeholders, product managers then write requirements, engineers then write designs. Finally this gets translated into jira epics/stories so engineers can do the implementation. The implementation runs in sprints so engineers can feel like they are doing agile. Finally when its all done, there's manual end to end testing with product and engineering.
Agreed! There's waterfall & agile and dogmatic & pragmatic. I've never worked on a dogmatic waterfall project but have worked on several dogmatic agile projects (that made me strongly wish I wasn't).
In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion.
The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).
Hardware development is almost exclusively Pragmatic Waterfall. It's pretty much a requirement. Lots of reasons. Too many to list here (it would probably not be useful).
As a software dev for hardware companies, most of my life, I splashed in a lot of waterfalls.
One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the project) put extensive effort into the requirements phase. Working on the requirements and removing requirement conflicts (a very common thing), understanding of requirements, feasibility of requirements etc. etc., and, at the final stage, a week-long meeting with everyone (customer, companies) to work out the last kinks. Only after that did the next phase start: Creating software requirements from the system requirements, and from there, an architecture and so on. And, as this was something involving many companies in many countries and even continents, having everyone on the same page was essential. And it did work. Of course in the years following the project there would be bugs etc, but not fatal ones (which are typically caused by errors in the requirements- and architecture phases).
(We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive)
EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.
It works if your client knows and can articulate exactly what needs to be made.
I imagine that was more common in the 80s and early 90s when most people working in computer land were more tech savvy (relatively) than your average project manager today. And the market was less “get it out there asap” than it is today.
In those days, having in-house competence to do the coding was very rare. With each step being much more connected to a specific area of competence. Hollywoods image of programmers was that they must not be seen anywhere near a customer.
This led to silos, where design was done by one group of people in the company, then sent to a third party contractor for a fixed scope and price.
This naturally creates a waterfall and when everybody just sees their own silo from inside, nobody questioned the big picture, nor that their own design would be flawed from the beginning. Until the product came back, not at all working as desired.
The biggest improvement today is that teams have much higher autonomy within their fully vertically integrated responsibilities. With wider areas of competence covered within a single team, or even a single person. As such, iterating and focusing on what is most important become more natural.
That's how I did waterfall. We would go through all the requirements, group things that were related, and assign them to a developer who owned them. Repeat until there are no more unsatisfied requirements.
By the second time, you actually have a reasonable chance of knowing what the requirements should have been the first time. They might even be valid for the rewrite, if things aren't moving too fast.
The bottom line is that (for many cases) you want to take advantage of the mutability of software while not just winging everything on the fly. There's probably a reasonable medium which will differ depending upon the use case.
It's funny because I had to take a company mandated 2 day Agile training class, and I thought the exact same thing. I thought "Waterfall" was just some concocted fantasy workflow to contrast with. I actually asked our instructor if it was real and he said "Of course it was!"
Waterfall was named as a strawman. However it is very similar to what a lot of projects do. No project does waterfall as described because there are always things that can't work that way. (some projects get closer to waterfall than others)
When people talk about Waterfall Model they forget the context of the era it originated. I've worked on a waterfall project early in my career. Please keep in mind that back in the 90s most software companies didn't have CI/CD, there was no cloud, releases were hand-delivered to the customer and usually rolled out about every 6 months because technically agile wasn't possible yet for most software shops. Waterfall was a valid method back then due to the technical (and cultural) limitations.
Haven't lived back then I'm not sure today's CD is better. Too often web breaks features people rely on. Worse they just do it randomly with no notice and no ability to have a transition time while you update. I miss the stability of knowing things will work like they did for a long time and when they break it is at a time I choose to apply the upgrade. (it didn't always work out this way, random bugs were a thing and still are)
Quality control was also a lot more important - you couldn't ship something with many bugs as customers would be forced to look at competitors if they hit your bug.
Meanwhile, the Royce paper that takes down the simplistic series of steps arranged in a waterfall, is a sort of formalization of an approach better visualized in late 80s as "the spiral model":
The concept of both, well before the 90s, is you don't know what you don't know, so its faster and more successful and costs less to make, learn, and document from prototypes before you know, to establish what you're really making.
The problem of Waterfall didn’t arise in the initial paper. It arose in subsequent interpretations. Particularly, see Parnas’ classic paper arguing that we should pretend to follow the “right” practices [which he defined as essentially Waterfall] even if we didn’t.
I call this Parnism. It’s Parnism we should fight, not Waterfall as such.
I worked at a place where, while it was never called "waterfall", it was absolutely the way things worked. I think it naturally evolves this way:
1) a software project, when finished, turns out not to fulfill all of the things people wanted
2) "we should plan more carefully next time, so that all the requirements are identified at the beginning"
3) the next software project starts to resemble waterfall, but still misses some requirements
4) "we should spend more time on the requirements phase next time, so we don't miss anything"
5) etc.
It is the natural method that large organizations end up with, in the absence of any philosophy saying otherwise. It's not the natural method that startups or small organizations end up with, probably, because it involves a ton of meetings first, before anything is done, and that is something that happens more in large organizations.
Waterfall is what you get when it is always the safer option to say, "wait, let's spend more time planning out and getting buy-in". There may not be many places that call it "waterfall", but there are a lot of places that do it. Some of them even call it "agile".
The way you can tell you're in one of these dysfunctional companies in my experiences is at the moment you, as a software developer, have to attend TWO meetings in one day. Companies that have too many meetings tend to have middle managers with only one goal for all these meetings: "Covering their ass." They treat these meetings as a way to collect evidence to be used later to prove that they weren't at fault when the project fails to meet it's objectives.
I'd say more than 5 meetings a week for an IC rather than two in a day. (I have 3 meetings a week, but two of them are coincidentally on the same day). Managers will naturally have more meetings.
I agree, you're right. I didn't think of it that way because most agile teams have a mandatory scrum meeting in the morning every day anyway. So a meeting is always literally the first thing you do...or at least it's your first interruption that comes right about the time you begin concentrating.
It's super counter-productive too because in the morning is when I'm at my most productive and a guaranteed interruption every single morning is horrible.
> It's super counter-productive too because in the morning is when I'm at my most productive and a guaranteed interruption every single morning is horrible.
At least in my bubble, tech seems to be skewed heavily towards night-owls. I winder if putting the meeting in the morning is due to people assuming that, since they aren't productive in the mornings, neither is anybody else.
In my 20s and 30s I wasn't productive in the morning mainly because chances are I was out half the night drinking. Since hitting my 40s, I'm most productive in the morning, because I'm never out late.
I have never seen waterfall in pure form. Mostly some kind of big upfront requirements projects with implementations iterations and a lot of project change management during the dev phase. These upfront requirements periods could be anything from a couple of weeks to a couple of years. While, I don't doubt that long requirements phases can have some value in aligning stakeholders on a new direction, they often became a raison d'être for complete teams - often stopping other promising projects in its wake: "You have to align with project jabberwocky before we can sign off your project." Agile seemed like a way to start early and get reduce the inherent waste by building software on paper upfront.
I don't think this post is quite accurate that Royce proposed the model just to critique it. Royce's 1970 paper describes a way of adapting normal project management practice to software.
Royce's criticism of the model touches on the brittle nature of specs in the face of discoveries about performance that mean a project could potentially have to start over.
Agile, however, has a lot more solid basis in the difficulty of estimating software development tasks. Using traditional project management tools, you would do a resource-leveled critical path analysis, which is a very heavyweight way of optimizing who does what and when, which then within a couple weeks is no longer useful because your task estimates suck. Instead you get. the team together every couple of weeks and decide who does what. Rinse and repeat.
Agile works better because estimates almost always suck but that's OK because that doesn't break your exquisiite schedule analysis because you're not making one.
Yep and here we are in 2024 and just this last week I got into a heated discussion with an 'Technical' Program Manager raging about how the deliverables are slipping by three days mostly because he and his up chain are heavily invested in a schedule that is built on hope. Not only are the estimates bad, but the resourcing from the different silos has not happened either, so there is tons of unfinished work just on the work that is known, let alone the unknown unknowns!
Next up he's about to find out his integration timeline is complete and utter bullshit.
Time to get a new TPM. Any TPM worth their salt should be doing everything in their power to catalog and mitigate those risks, and communicate them upwards. Lack of communication in both directions and adversarial conversations with engineers is a whole parade of red flags.
That said, Gantt charts absolutely have their place alongside Agile. Our budget and goals are set yearly so inevitably there’s going to be milestones and work back dates to meet, as well as cross-team/org dependencies to track.
Waterfall is a straw man, early descriptions by Royce were written specifically to criticize it. Waterfall is mentioned in relation to agile to sing agiles praises. No serious developer will claim to use waterfall.
There are however, a suite of scientific management approaches based on the work of Henry Gantt which have been used, and are used today, that fit under the umbrella of waterfall approaches, such as the program evaluation and review technique, critical path, critical chain, and earned value. These are still in use today, and in fact government contractors are legally required to use earned value for acquisition programs over a certain value.
1. You're a contracting house, your clients are hopeless, and you just want to start billing hours, and keep billing hours every 1-2 uninterrupted weeks of peace. Clients saying something different every 1-2 weeks is no significant harm done, since you don't have to care, you just want to keep billing hours.
2. Possibly in-house rather than contracting, stakeholders and developers collectively have little idea what they're doing, whether in the problem/system domain or in process, so planning is mostly pretend and counterproductive, and best minimized. Just do something now, and everyone will quickly see whether it looks in the right direction. And where this model breaks down, you can duct tape it with firefighting meetings that have some people looking like heroic decisive leaders with a bias for action (win).
That's fine, but these people should quietly enjoy their Agile, keep their heads down, and stop trying to evangelize Agile to people who don't have (or are getting rid of) either of the above two dynamics. Also, if they find themself saying "Waterfall", that's probably a reminder that they've accidentally started evangelizing, and in a parroting way.
I think what you're trying to say is that there is no one development process that fits every situation because all situations are different and thus what you need to do to have a successful software project is adapt the process to the business and do what works.
> these people should quietly enjoy their Agile, keep their heads down, and stop trying to evangelize Agile to people who don't have (or are getting rid of) either of the above two dynamics.
I disagree. I've seen more than my fair share of people signing on "big" IT contracts that promise nothing except specifications before Y+2 or Y+3, and these people need to see the light. To date, I have never seen any multi-year software project that doesn't start delivering early land softly. And whenever they crash, it's the teams that suffer.
OK, they should limit themselves to evangelizing to dynamics #1 and #2. Something like:
1. "You people only care about billing hours, and Agile is how you do it nicely."
2. "This/these organizations are systemically incapable of coordinating effectively on something like this, so Agile is probably your best bet for eventually reaching a passable solution, and reassuring people in the meantime."
3. Hot shot VP in non-software company starts a small in-house software team that immediately has to manage multiple small/intermittent software projects where the product owners are half not paying attention / half don't care, and the team just wants them in the room at least once or twice a week.
This drama has played out in almost every company over a certain size in America I'm sure
I feel like this post has some nuance or clever wordplay that I'm missing. So if that's the case, apologies for adding noise.
But in the real world, the waterfall model was absolutely not a "strawman", but instead was literally how almost all software was built, up to even the turn of the century and beyond. Software projects were smaller in general, compiling was a major undertaken, you collaborated on projects by sending files around or, best case, working on a shared network directory. The pace of change of tooling and "libraries" was much slower and more predictable.
As we got source control, intellisense, massive knowledge bases, and then the rapid iteration of code sharing in the form of libraries and so on, things started changing because the model was too slow. But it was absolutely real and the norm.
Not exactly. From first principles, it could only possibly work if the project was very well-known/trodden ground already. So of course mistakes were either fixed when discovered or the project failed.
(Yes, some govt projects pretended to follow a strict process. What’s new?)
But even Brooks’ original MMM (1975) encouraged iteration as a way to validate assumptions.
Yeah this is strange how every agile coach has a sales script that begins with extolling the evils of waterfall.
It's far more likely that the customer/boss adds features and requirements way late in the process. As an anecdote, I was working on a small mobile app, and two days before release date, my boss came in and demanded that I make the app work on ancient iPhone's with tiny screens, which involved having to redesign large parts of the UI to reflow in ways I hadn't thought of. He justified this by being 'agile' and 'forward thinking'
Plenty of people have written books that confirm/deny the efficacy of the Waterfall model.
But in the meantime, there are far, far many more folks - by significant orders of magnitude - who have written software with the Waterfall model.
Far, far more.
The fact that it is still with us, and can still be used quite effectively sort of leads credence to the idea that those who can, do, while those who can't, teach (or write books about it).
- author agrees that there are people that actually use it as a methodology for their software projects
- But because no one wrote a book about it, author assumes talking about "the waterfall model" a strawman.
To me, this sounds like moving the goalposts. One comment fits my experience :
> The Waterfall model IMHO comes from Taylorism. Is a serial assembly line that follows an strict division of labor, management that thinks and workers that execute, etc. Having worked with professionals beyond sw development, they don't call it "Waterfall" but it is everywhere.
Yeah this kind of thing definitely happened all the time at big corporations 30+ years ago as well and it comes from traditional engineering projects where changes later on in the process are very very expensive.
The waterfall method is EVERYWHERE, entrenched, systematic, and pervasive. Even when you're supposedly doing Agile, there's always half the team still thinking in waterfall.
In any non-digitally-native company, including many F500s, waterfall still happens, is still happening, has always been happening, will likely continue to happen.
And you know what? That's okay. Choose the tools that fit the job, not fit the job to the tool.
Why do you think it's more prevalent in non-digitally-native companies? I've often wondered if it's because those companies are uncomfortable with software development in the first place, so it makes them feel better to have a finish date for the project.
But also, if you're making hardware for example, you can't just go back and 'update' the molds, the assembly line, change the material composition, etc. The lead times are insane, the changes are expensive, and the downstream consequences can be disastrous. This applies to everything from medicine, to farming, to government.
I dive into this in my blog, "What is your alternative to Agile?" - https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... - but the Structured Systems Analysis and Design Method as well as PRINCE2 were common in the industry, but both were examples of methodologies that took waterfall and codified it. However, the last waterfall project I was on was in 2013. We had formal gates out of each section of the process. (Even there, we tried to make it as incremental as possible, but it was a Fortune 500 company that had an overarching process.)
You also have to remember that there are a lot of software projects that do have a "done" state, after which the project goes into maintenance until there is more funding for improvements. Consider an internal project to turn a department excel sheet into an application. You can quickly reverse engineer the current behavior, go to the stakeholders and get a set of the desired behaviors above and beyond what the spreadsheet does, negotiate a scope, write a small design document, and just go do it. You then demo it at the end and change what is necessary before they start using it. You have a small set of bug fixes and QOL improvements that follow, then the project is handed off to a team managing 500 similar projects overseas and is responsible for security and bug fixes.
This doesn't make sense in product companies for good reason. However, on small projects, waterfall can work.
The Royce paper is actually still worth reading. It's well written and if you can step over the 50+ years of history since then also still somewhat informative. And of course the word waterfall doesn't actually appear in it. That word was slapped on it by others afterwards. And of course Royce vaguely suggests that going through the steps more than once might be helpful. What we now call iterating.
The key concept for what we now call agile (which mostly boils down to variations of scrum these days) actually has roots dating back about half a century. People were suggestion spiral development at some point (converging on some final thing) as early as the eighties. There was the whole 4+1 model which got caught up in the whole UML movement and it's associated process.
The key innovation that extreme programming (one of original agile methodologies) brought was that increasing the iteration frequency and giving up on the notion that you can do a lot of requirements and design up front. Things change. Every iteration. So having a lot of requirements and design documentation to update every cycle is counter productive. Dropping that was considered extreme. But then people realized that that worked just fine and that these designs were kind of low value artifacts to begin with. Not really worth the hassle.
With Spiral, the iterations explicitly involve the customer. This is important.
With Waterfall, there is an upfront spec, but implementing the whole thing without consultation with the customer can be a bad experience.
With Agile, maybe there's a lot of internal correction. But the key thing is to involve the customer in integration testing. Unless both sides are very experienced, surprises due to miscommunication are the rule.
It's mainly iteration length that has shortened. Royce was saying do it twice (including requirements engineering, which presumably would involve some kind of feedback). Spiral development increased that to doing it multiple times. Rational unified suggested a quarterly pace. Most agile methodologies work with sprints of a few weeks.
And lately, continuous deployment and Kanban like methods remove iterations completely and release continuously. Ship when ready and develop asynchronously. You can still have planning cycles with this of course but they are decoupled from release cycles.
The Linux kernel is a good example where you either make the merge window or wait for the next one. Large companies like Meta are also know to work with scheduled releases that are independent from planning cycles (e.g. weekly) of teams.
The irony is that the proposition that "someone wrote a book that proposed waterfall as the best software method" is itself a strawman argument.
To my knowledge, that has never been claimed.
Waterfall is what many of us old fogies in the industry experienced as the "defacto" methodology for a long time. It made intuitive sense that in order to design a build a project that you would first, you know, DESIGN it. Then you'd kick over that design to software developers that were expected to implement it.
Iteration in the design and development process, the idea of "people before process" and getting designers and engineers to collaborate early on etc. was not obvious. That's where all of Agile's "waterfall" talk came from. The fact that for a long time what companies were doing, while never exactly the same process as each other, was always waterfall-like because that's what made the most sense in an industry that was very new and in which no one knew wtf they were doing... so they took knowledge from other domains and tried to make it fit. That's a large part of what Fred Brook's The Mythical Man Month talks about.
It's only now that a new generation of developers has come up in a world where all they've ever known was "Agile" and "Scrum", that the world they know is so far removed from the "non-Agile" world that these books describe.
A colleague of mine the other day was talking about experimenting with something using the browser's `postMessage` API 8 years ago. My initial reaction was "did postMessage exist 8 years ago?" And then I remembered that 8 years ago was 2016 and it's already 2024. Many "experienced" people coding today have 5 years experience... and then they talk about concepts that were a reaction to how things were being done in the 80s and 90s as if those decades never happened ... because if they had even been born yet they were still children, so they weren't there to live that reality and the pain that what came later was a reaction to.
"Waterfall" is just a pejorative term used against the kind of project management that uses a Gantt chart, which kinda looks like a waterfall. This kind of project planning is necessary when you've got engineering steps that are time sensitive and take months to years. Like if you're building a large bridge you need to schedule the resources to do individual steps a long time in advance.
Writing software was initially run like this and there was a big pushback because most of those old school engineering methodologies just aren't justified because when you're writing software all of the steps look pretty similar and the design/build/test cycle can go through a full cycle in minutes instead of years and you get to do it millions of times instead of, like for a bridge, only once.
Those engineering practices are still necessary when you're building things, sometimes a bit less so with electronics hardware these days we have prototyping that can turn around very quickly, but still if you're doing a large physical engineering project, you do lots of "waterfall" because that's the best tool for the job because the job requires it.
Which, given that that's a military spec, also speaks to a motivation for such a tightly controlled approach: the cost of design changes is truly immense. When you have a large government project with MANY different contractors working on different pieces of the system, a lot of Agile principles need to go out the window. The spec needs to be fairly well nailed down up front because a late change that affects adjacent systems gets really expensive when those adjacent systems are being managed by a completely different company. That requirements tweak may now be a full on contract renegotiation. And, as Boeing's recent woes illustrate, communication among all the subcontractors may be so poor that even identifying the potential impact of a specification change may be difficult to do reliably.
Not such a big deal in a lot of tech projects where it's relatively inexpensive to solve problems as you find them. But Mars rovers don't get to have canary deployments.
Also, even then, it's still not really "textbook" waterfall.
> designers and engineers to collaborate early on etc.
The really scary thing to me is that I'm old enough to remember when all the trade rags were excitedly talking about how it's a great idea to not just "throw your design over the wall" but work with the software guys to understand what their needs were and accommodate them.
The scarier thing is that they were talking about this in the year 2000.
Royce's paper is one of the best pieces on how to manage software projects that I've ever read. It's quite short, but every time I re-read it I notice a new insight I hadn't noticed previously.
Royce did not present that waterfall diagram as a straw man. The structure of the paper is itself rather agile: he starts with the simplest thing that could possibly work, identifies problems with it, and then progressively iterates on it.
That certain people in the Agile community continue to perpetuate the myth that this model is a serious thing that people actually thought was a good idea might be a straw man. But ignoring the rest of the paper is probably good strategy. That one page is a useful starting model for them, too. But they really woudln't want to call attention to any other page of the paper. The rest of the pages are too full of hard-won observations that speak to why Scrum seems to work out so poorly in practice for large, multi-team projects.
174 comments
[ 2.9 ms ] story [ 211 ms ] threadPeople mocked things and prototyped things but I sat beside people who worked for 2 years or more on wall sized collections of ring binders of requirements specifications and flow charts, to end in acrimonious lawsuits.
I do kind of hate agile language. It's smug. But I love rapid prototypes and sprints.
My field is not enterprises though, I worked all of my 20+ years career at tech companies of different sizes (from startups to 10k+ people orgs), startups and smaller companies usually will throw a PoC into production, and call it "tech debt" for later, larger orgs tend to avoid that since they've been previously burnt by the maintenance burden of poorly designed code in production (usually on their startup-ish phase).
https://www.praxisframework.org/files/royce1970.pdf
I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified, with the whole design- and implementation phase based on this, with milestones where each step of the waterfall would be delivered and checked by the customer. This was particularly prevalent back in the eighties and beginning of the nineties. It's as real as can be, it did exist. Obviously developers couldn't follow that 100%, so there would be some amount of back-designing an earlier stage, but if it wasn't 100% it was very close in practice too.
I think a real criticism of Agile would be that it works great assuming a) domain expertise and b) good understanding of how accurate / precise a solution has to be to work.
Agile seems to work best when the domain itself is technology, rather than, say, when the domain is HVAC control or real-time ECMs.
It's still the case in many trades. You don't build a house or a bridge the Agile way for instance.
IMHO Agile got a lot more prevalent because the planning phase became more and more onerous to have any reliability, and management was tired of paying upfront for it. I steady they could get a more regular billing (in particular when dealing with consulting companies) with reports of stuff allegedly shipped, instead of six months of "we're planning very hard, just trust us". Whether the end result matched what they needed/wanted to build being another story.
I know many companies that had an official Waterfall cycle, while actually working on something more granularly shipped with many phases of prototyping. And they didn't move to Agile either, just stopped calling their process anything and went on doing whatever felt right.
Looking at how some houses are built these days, a case could be made for Agile over "do your best, silicone the rest".
I can even support an agile process to create waterfall process.
In every single company I have worked, the process always took priority. It's made even worse where you have ISO 9001 compliance where every god damn thing in the company is locked into a "process." Process over people, period. Coporo-managers can't get it out of their head.
When all you have ever done is "the process" it looks perfectly sane. To teams that can produce a POC and basically get to market on their own domain knowledge, it looks ridiculous. Making developers wait for requirements instead of inventing them on the fly is incredibly slow and smothers nearly all innovation.
Why risk making your product look like your convoluted communication and political structures? The entire point of agile was lost on the influx of bodies to the industry.
Form a "skunk works" team and shield them. Make a big show of how their success came despite having zero fucking process. Jira is for maintenance.
How is it my fault? I don’t get to make the decisions and I can’t just change jobs if management doesn’t listen.
Then again, I doubt the company has a reward structure in place that even makes the mental energy worth expending.
If you aren't on the way up, then you are on the way out.
If process (or freedom from process) is important to you, you need to make it a priority when you're interviewing. May depend on what industry you work in, of course, some industries don't have any cowboys.
That said, I like my cowboy jobs with a little bit of process. What's deployed in production should be reflected in source control, but I'm not a stickler for which comes first. A change notification should be posted before production is changed, but if you have separate push and load steps, you can push before you notify (if pushing takes a while, it's good pipelining to use the push time to compose your change notice). Changelogs usually shouldn't be 'bugfixes' or 'latest', but 'fixing' is appropriate for a close in time followup. That's process, even if an ISO compliance officer would lose their mind.
I was a software engineer in the 90s at a small company (15 people) doing simulation development for the UK Ministry of Defence. We had two distinct software development processes, which were waterfall and a form of rapid development known as the Dynamic Software Development Method (DSDM). (I threw away the manuals years ago so can’t give more info).
The company directors came from an aerospace background so had a very strong software quality focus. Many of our contracts specified waterfall and our project artefacts reflected that – user requirements docs, system requirements, architectural design, detailed design, integration test plans, system tests, acceptance tests, etc etc. Coding happened somewhere in the middle. It did work, sort of, in situations where the customers knew what they wanted, and we mutually understood it. Which was quite often the case, for our regular customers on projects that were extending existing systems.
We trialled DSDM for projects where the customer said ‘prototype’ and I liked it. It lacked the onerous agile / scrum boilerplate and IIRC was based around loosely specified timeboxes and relied on having ‘intelligent customers’ who were prepared to be flexible in terms of what they got at the end.
The need for DSDM was motivated by a project that failed badly (not with the MOD) because the customers said ‘here are our requirements for this prototype system, don’t come back until you have finished and tested it’. Needless to say the result wasn’t what they expected, even though all of the requirements had been, on paper, met.
But for any development where specific technical outcomes were necessary (e.g. a maths module), waterfall would usually be used.
Key what I remember was time boxing. And much less religious stance than Agile. But back then it was normal to have different people doing functional designs, technical designs, database design (also in two levels) and business process design of sorts. I guess it took a while for these people to realise they had to be Agile digital transformers.
And I guess it also did not help the DSDM also certified people on the waterfall methodology.
If you're building a house, or something bigger, you don't just start nailing lumber together. You have a blueprint. Pretty detailed, and it uses industry-standard terms and markup. Any builder can take it and use it to construct the building. It has the dimensions and specifications for the foundation and all the rooms. It has considered where the rooms are, which walls are load bearing, where the staircases and HVAC and plumbing and electrical runs are, where the windows and doors are, pretty much everything. An engineer has signed off on the overall design as being safe and meeting all the applicable codes. You can order a list of supplies based on this plan and you'll be within a few percent of what you actually use.
Some small changes were allowed. You could change finish details like what style of cabinets or trim or door knobs would be used. But you could not really approach the builder once the framing was complete and say actually I wanted the living room over there and the bedrooms over here and also I want to add a third storey. You also didn't build one bedroom, and then based on that experience extrapolate the design for the next one, and then apply that to building the kitchen, and so on. It was all done up front.
People, especially people who were used to managing physical projects, thought that with the same level of planning, and the same approach to management, the same results could be achieved in software projects.
On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common.
It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan.
I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation.
And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
You captured so much in this one sentence, especially the end, about how waterfall failed the developer, rather than the developer having failed waterfall.
This script-flip works on many other systematized orthodoxies, I suspect.
I consider it a straw man because, as the agile crowd describes it, there appears to be no such thing as "waterfall". Perhaps that is the result of comical oversimplification rather than a conscious attempt at deception (I believe this is the case), but it still results in standing up a straw man so it can be knocked down.
I just haven't seen that happen. I'm sure there are exceptions where it has, but I think those have always been rare.
If the software industry had the equivalent of "general contractors" who pour the concrete, wire the rebar, dig and fill the holes, install the electrical and duct, laid the bricks, all to within the tolerances specified; AND had architects who knew both the tools available and the domain inside and out, a model mirroring the real estate industry MIGHT BE doable. But there are a lot of differences beyond just the "engineering" aspects (and often times, the head engineer on a project is not the architect).
In that, he first introduces what has come to be known as Waterfall. While he considered it to be fundamentally sound, he posits that it carries significant risk and then goes on to tell what needs to be added to diminish the risk. Those additions are what oft get called Agile (although not in the Manifesto sense).
You have a point that "simplification" is more in line with the device he was trying to use, but with the intent of leading you into understanding the more complex aspects of his idea. Kind of like that owl drawing meme where you start with two circles and then draw the rest of the owl. There is only one idea present. In other words, "Waterfall" and "Agile" are the exact same thing, just at different stages of communication.
Where others have tried to invent "Waterfall" as it own distinct thing to contrast with "Agile", it would be fair to characterize that as a strawman. If anything all projects are "Agile" at their core, with varying degrees of deviation happening in a multi-dimensional space.
In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall.
Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement.
You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.
There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.
Remember that this is largely about consultants selling advice to executives. This is not about getting stuff done.
BUT software is also a young industry. We just don’t know yet the right way to do it so we discuss and share what’s worked for us. Just like it took a while to find the right manufacturing processes in other industries.
Sure, you do requirements elicitation, review and documentation, and then architectural design, followed by detailed design & coding, etc. But it's never a linear process end-to-end. There's always feedback. There's always something you didn't account for showing up and requiring a change to an earlier part of the process.
Waterfall can, and does work, but only on fairly small projects that can be completely defined correctly the first time around. And like everything else, it's easier if you've done that kind of project before.
There's often a clear goal in these cases, and there's no 'minimum valuable product' you can quickly iterate on.
When you spend more time trying to update your design to match the implementation (via change requests) than implementing you start to wonder if there's maybe a better way..
And I note that government contracting was probably a bigger fraction of all software engineering in the 1980s than it is today. (Still more in the 1960s.)
So, yes, it was real. It is mercifully less prevalent than it was.
Naturally nothing worked and everything was late.
https://upload.wikimedia.org/wikipedia/en/6/65/Screengrab_-_...
One way I've weaned people off waterfall approaches is just to tell them yes, of course that's what we're doing, but to make it extra safe, we'll produce software early and often so you can see progress. Then eventually I'll slip in getting users to try it, just for "testing". And then getting it deployed early, for more "testing". The smart ones get engaged in this process, using it to making things better than the initial conceptions. They may produce waterfall documents for a while, especially if they need to pacify higher ups. But often they'll just forget. I think them GANTT charts and the like were always a ritual to get them feelings of control, and they stop doing that work once they have actual control.
So I suspect a lot of the nominal waterfall projects of yore were similarly made to work by developers just doing the right thing in quiet ways while saying, "Oh, that's 90% complete for sure. Mark it on your chart!"
I was a kid who didn't make grammar/spelling mistakes. I'd just write up the paper, insert two or three errors, submit it, and then a couple days later submit the original version.
Its funny because that would the inverse of the current situation where exec proclaims their company is agile to external observers and potential hires, but the de facto regime could be anything
I've never felt so old in my life
I'm on a project now trying to manage external customer cutovers and integrations using JIRA and its a dumpster fire.
A proper project plan with deadlines, lead times, resources etc would solve 99% of the problems.
Its just non stop crisis "oh we forgot to get get change submitted on time" - "oh this customer can't migrate until date x" - "oh this test environment is down for scheduled rebuild on days xyz" - all can easily be tracked to automatically calculate timelines.
Agile is fine at a macro level, but it needs to feed into a better system for real world dependencies and deadlines.
Still does, sadly.
I think this is one of the things that don't explicitly follow the waterfall diagram as presented and criticized though. You're delivering smaller units of work here and I presume incorporating their feed back at least to the extent of if it is functionally meeting the specified requirements which is kind of agile-y.
The main difference between the two at that point seems to come down mostly to the willingness to revisit the requirements which even when my employer was more waterfall we would try to incorporate changes if the customer came back and said what we were doing wasn't going to work at all or they needed changes.
If you are producing anything a customer might actually before the very end of the project, it's not waterfall.
Waterfall is great for high level governance (such as specifying high level milestones). Agile is great for executing on the deliverables.
It is jus my experience. You're miles may vary.
Fact is, long-lived products, esp. from BigCorps, and esp. those in heavily regulated spaces like medicine and transportation always have and always will spend a lot more time and effort on design and process than will ephemeral products and services from startups. My software career started ca. 1990 just as waterfall was evolving into the 'Spiral' iterative software model, which since has been rebadged and remorphed several times into today's 'agile' and 'test-driven' gift from god. However in the real world, makers of every S/W product inevitably must adapt their actual development process to suit the lifecycle needs of their product and customer, in ways that scrum can't serve. Often the best way to reduce technical debt is to increase investment design and testing. And taken to NASA-like limits of fault-tolerance and reliability, that can take you all the way back to waterfall.
Have you considered calling it Rapids development? You will sell a million books or whatever, just on the name.
A variation of this exists with one more word thrown in for good measure: https://en.wikipedia.org/wiki/Rapid_application_development
Building such an product in agile was often tried and failed in the past decade. You need common data structures and routines that a few thousand developers can all expect to find ready further down the line. Like the Oregon Trail game, you launch all workstreams in different moments and expect them to converge at the finish line.
I think “100% waterfall” was ditched in the early 90s, for all the known reasons, with smaller cycles of releases becoming the norm. But still the hard thinking, laying down the key mechanisms of a platform was heavily thought out early on.
I think all criticism is a bit unfair, as agile is also an infinite source of cock ups, mediocrity and dead ends just as waterfall. There is a space for each approach, and bottom line, the right people will make all the difference. But that’s also why it’s important to learn and respect both approaches…
One of the reasons that waterfall was a reasonable way to proceed was that, in the past, tighter coupling to hardware and longer hardware lead times meant the need to design and specify in advance. This is still somewhat the case where these conditions are true, albeit to a lesser degree.
But I think it's basically a fairy tale. "And they lived happily ever after" for executives. And I can prove it. There are basically no successful products that started with an executive idea, were created in a waterfall fashion, and then stayed at that initial version forever. Waterfall is built on the fantasy of managerial omniscience, where the people in charge know everything important on day 1. But the reality is that the beginning of a project is when we know the least. Waterfall in practice is a bet nobody will learn anything as time goes on. And on waterfall projects, that often turns out to be true, if only because course corrections would cause executives to lose face.
In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion.
The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).
As a software dev for hardware companies, most of my life, I splashed in a lot of waterfalls.
(We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive)
EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.
I imagine that was more common in the 80s and early 90s when most people working in computer land were more tech savvy (relatively) than your average project manager today. And the market was less “get it out there asap” than it is today.
This led to silos, where design was done by one group of people in the company, then sent to a third party contractor for a fixed scope and price.
This naturally creates a waterfall and when everybody just sees their own silo from inside, nobody questioned the big picture, nor that their own design would be flawed from the beginning. Until the product came back, not at all working as desired.
The biggest improvement today is that teams have much higher autonomy within their fully vertically integrated responsibilities. With wider areas of competence covered within a single team, or even a single person. As such, iterating and focusing on what is most important become more natural.
https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
It is hard to foresee how the world of development would look like today, had companies used the waterfall process twice on each project.
[0] https://dl.acm.org/doi/10.5555/41765.41801
Now I don't know what to think!
Quality control was also a lot more important - you couldn't ship something with many bugs as customers would be forced to look at competitors if they hit your bug.
If you want to see a valid method "back in the 90s", see DSDM:
https://en.wikipedia.org/wiki/Dynamic_systems_development_me...
Meanwhile, the Royce paper that takes down the simplistic series of steps arranged in a waterfall, is a sort of formalization of an approach better visualized in late 80s as "the spiral model":
https://en.wikipedia.org/wiki/Spiral_model
The concept of both, well before the 90s, is you don't know what you don't know, so its faster and more successful and costs less to make, learn, and document from prototypes before you know, to establish what you're really making.
I call this Parnism. It’s Parnism we should fight, not Waterfall as such.
1) a software project, when finished, turns out not to fulfill all of the things people wanted
2) "we should plan more carefully next time, so that all the requirements are identified at the beginning"
3) the next software project starts to resemble waterfall, but still misses some requirements
4) "we should spend more time on the requirements phase next time, so we don't miss anything"
5) etc.
It is the natural method that large organizations end up with, in the absence of any philosophy saying otherwise. It's not the natural method that startups or small organizations end up with, probably, because it involves a ton of meetings first, before anything is done, and that is something that happens more in large organizations.
Waterfall is what you get when it is always the safer option to say, "wait, let's spend more time planning out and getting buy-in". There may not be many places that call it "waterfall", but there are a lot of places that do it. Some of them even call it "agile".
It's super counter-productive too because in the morning is when I'm at my most productive and a guaranteed interruption every single morning is horrible.
At least in my bubble, tech seems to be skewed heavily towards night-owls. I winder if putting the meeting in the morning is due to people assuming that, since they aren't productive in the mornings, neither is anybody else.
Royce's criticism of the model touches on the brittle nature of specs in the face of discoveries about performance that mean a project could potentially have to start over.
Agile, however, has a lot more solid basis in the difficulty of estimating software development tasks. Using traditional project management tools, you would do a resource-leveled critical path analysis, which is a very heavyweight way of optimizing who does what and when, which then within a couple weeks is no longer useful because your task estimates suck. Instead you get. the team together every couple of weeks and decide who does what. Rinse and repeat.
Agile works better because estimates almost always suck but that's OK because that doesn't break your exquisiite schedule analysis because you're not making one.
Next up he's about to find out his integration timeline is complete and utter bullshit.
That said, Gantt charts absolutely have their place alongside Agile. Our budget and goals are set yearly so inevitably there’s going to be milestones and work back dates to meet, as well as cross-team/org dependencies to track.
There are however, a suite of scientific management approaches based on the work of Henry Gantt which have been used, and are used today, that fit under the umbrella of waterfall approaches, such as the program evaluation and review technique, critical path, critical chain, and earned value. These are still in use today, and in fact government contractors are legally required to use earned value for acquisition programs over a certain value.
1. You're a contracting house, your clients are hopeless, and you just want to start billing hours, and keep billing hours every 1-2 uninterrupted weeks of peace. Clients saying something different every 1-2 weeks is no significant harm done, since you don't have to care, you just want to keep billing hours.
2. Possibly in-house rather than contracting, stakeholders and developers collectively have little idea what they're doing, whether in the problem/system domain or in process, so planning is mostly pretend and counterproductive, and best minimized. Just do something now, and everyone will quickly see whether it looks in the right direction. And where this model breaks down, you can duct tape it with firefighting meetings that have some people looking like heroic decisive leaders with a bias for action (win).
That's fine, but these people should quietly enjoy their Agile, keep their heads down, and stop trying to evangelize Agile to people who don't have (or are getting rid of) either of the above two dynamics. Also, if they find themself saying "Waterfall", that's probably a reminder that they've accidentally started evangelizing, and in a parroting way.
I disagree. I've seen more than my fair share of people signing on "big" IT contracts that promise nothing except specifications before Y+2 or Y+3, and these people need to see the light. To date, I have never seen any multi-year software project that doesn't start delivering early land softly. And whenever they crash, it's the teams that suffer.
1. "You people only care about billing hours, and Agile is how you do it nicely."
2. "This/these organizations are systemically incapable of coordinating effectively on something like this, so Agile is probably your best bet for eventually reaching a passable solution, and reassuring people in the meantime."
This drama has played out in almost every company over a certain size in America I'm sure
But in the real world, the waterfall model was absolutely not a "strawman", but instead was literally how almost all software was built, up to even the turn of the century and beyond. Software projects were smaller in general, compiling was a major undertaken, you collaborated on projects by sending files around or, best case, working on a shared network directory. The pace of change of tooling and "libraries" was much slower and more predictable.
As we got source control, intellisense, massive knowledge bases, and then the rapid iteration of code sharing in the form of libraries and so on, things started changing because the model was too slow. But it was absolutely real and the norm.
(Yes, some govt projects pretended to follow a strict process. What’s new?)
But even Brooks’ original MMM (1975) encouraged iteration as a way to validate assumptions.
It's far more likely that the customer/boss adds features and requirements way late in the process. As an anecdote, I was working on a small mobile app, and two days before release date, my boss came in and demanded that I make the app work on ancient iPhone's with tiny screens, which involved having to redesign large parts of the UI to reflow in ways I hadn't thought of. He justified this by being 'agile' and 'forward thinking'
But in the meantime, there are far, far many more folks - by significant orders of magnitude - who have written software with the Waterfall model.
Far, far more.
The fact that it is still with us, and can still be used quite effectively sort of leads credence to the idea that those who can, do, while those who can't, teach (or write books about it).
- there is this thing called "waterfall"
- author agrees that there are people that actually use it as a methodology for their software projects
- But because no one wrote a book about it, author assumes talking about "the waterfall model" a strawman.
To me, this sounds like moving the goalposts. One comment fits my experience :
> The Waterfall model IMHO comes from Taylorism. Is a serial assembly line that follows an strict division of labor, management that thinks and workers that execute, etc. Having worked with professionals beyond sw development, they don't call it "Waterfall" but it is everywhere.
What if I had a smoking gun?
https://www.product-lifecycle-management.com/download/DOD-ST...
The waterfall method is EVERYWHERE, entrenched, systematic, and pervasive. Even when you're supposedly doing Agile, there's always half the team still thinking in waterfall.
In any non-digitally-native company, including many F500s, waterfall still happens, is still happening, has always been happening, will likely continue to happen.
And you know what? That's okay. Choose the tools that fit the job, not fit the job to the tool.
But also, if you're making hardware for example, you can't just go back and 'update' the molds, the assembly line, change the material composition, etc. The lead times are insane, the changes are expensive, and the downstream consequences can be disastrous. This applies to everything from medicine, to farming, to government.
Whereas software you just push new code to prod.
You also have to remember that there are a lot of software projects that do have a "done" state, after which the project goes into maintenance until there is more funding for improvements. Consider an internal project to turn a department excel sheet into an application. You can quickly reverse engineer the current behavior, go to the stakeholders and get a set of the desired behaviors above and beyond what the spreadsheet does, negotiate a scope, write a small design document, and just go do it. You then demo it at the end and change what is necessary before they start using it. You have a small set of bug fixes and QOL improvements that follow, then the project is handed off to a team managing 500 similar projects overseas and is responsible for security and bug fixes.
This doesn't make sense in product companies for good reason. However, on small projects, waterfall can work.
The key concept for what we now call agile (which mostly boils down to variations of scrum these days) actually has roots dating back about half a century. People were suggestion spiral development at some point (converging on some final thing) as early as the eighties. There was the whole 4+1 model which got caught up in the whole UML movement and it's associated process.
The key innovation that extreme programming (one of original agile methodologies) brought was that increasing the iteration frequency and giving up on the notion that you can do a lot of requirements and design up front. Things change. Every iteration. So having a lot of requirements and design documentation to update every cycle is counter productive. Dropping that was considered extreme. But then people realized that that worked just fine and that these designs were kind of low value artifacts to begin with. Not really worth the hassle.
With Waterfall, there is an upfront spec, but implementing the whole thing without consultation with the customer can be a bad experience.
With Agile, maybe there's a lot of internal correction. But the key thing is to involve the customer in integration testing. Unless both sides are very experienced, surprises due to miscommunication are the rule.
And lately, continuous deployment and Kanban like methods remove iterations completely and release continuously. Ship when ready and develop asynchronously. You can still have planning cycles with this of course but they are decoupled from release cycles.
The Linux kernel is a good example where you either make the merge window or wait for the next one. Large companies like Meta are also know to work with scheduled releases that are independent from planning cycles (e.g. weekly) of teams.
To my knowledge, that has never been claimed.
Waterfall is what many of us old fogies in the industry experienced as the "defacto" methodology for a long time. It made intuitive sense that in order to design a build a project that you would first, you know, DESIGN it. Then you'd kick over that design to software developers that were expected to implement it.
Iteration in the design and development process, the idea of "people before process" and getting designers and engineers to collaborate early on etc. was not obvious. That's where all of Agile's "waterfall" talk came from. The fact that for a long time what companies were doing, while never exactly the same process as each other, was always waterfall-like because that's what made the most sense in an industry that was very new and in which no one knew wtf they were doing... so they took knowledge from other domains and tried to make it fit. That's a large part of what Fred Brook's The Mythical Man Month talks about.
It's only now that a new generation of developers has come up in a world where all they've ever known was "Agile" and "Scrum", that the world they know is so far removed from the "non-Agile" world that these books describe.
A colleague of mine the other day was talking about experimenting with something using the browser's `postMessage` API 8 years ago. My initial reaction was "did postMessage exist 8 years ago?" And then I remembered that 8 years ago was 2016 and it's already 2024. Many "experienced" people coding today have 5 years experience... and then they talk about concepts that were a reaction to how things were being done in the 80s and 90s as if those decades never happened ... because if they had even been born yet they were still children, so they weren't there to live that reality and the pain that what came later was a reaction to.
Writing software was initially run like this and there was a big pushback because most of those old school engineering methodologies just aren't justified because when you're writing software all of the steps look pretty similar and the design/build/test cycle can go through a full cycle in minutes instead of years and you get to do it millions of times instead of, like for a bridge, only once.
Those engineering practices are still necessary when you're building things, sometimes a bit less so with electronics hardware these days we have prototyping that can turn around very quickly, but still if you're doing a large physical engineering project, you do lots of "waterfall" because that's the best tool for the job because the job requires it.
https://en.wikipedia.org/wiki/Gantt_chart
Which, given that that's a military spec, also speaks to a motivation for such a tightly controlled approach: the cost of design changes is truly immense. When you have a large government project with MANY different contractors working on different pieces of the system, a lot of Agile principles need to go out the window. The spec needs to be fairly well nailed down up front because a late change that affects adjacent systems gets really expensive when those adjacent systems are being managed by a completely different company. That requirements tweak may now be a full on contract renegotiation. And, as Boeing's recent woes illustrate, communication among all the subcontractors may be so poor that even identifying the potential impact of a specification change may be difficult to do reliably.
Not such a big deal in a lot of tech projects where it's relatively inexpensive to solve problems as you find them. But Mars rovers don't get to have canary deployments.
Also, even then, it's still not really "textbook" waterfall.
The really scary thing to me is that I'm old enough to remember when all the trade rags were excitedly talking about how it's a great idea to not just "throw your design over the wall" but work with the software guys to understand what their needs were and accommodate them.
The scarier thing is that they were talking about this in the year 2000.
Royce did not present that waterfall diagram as a straw man. The structure of the paper is itself rather agile: he starts with the simplest thing that could possibly work, identifies problems with it, and then progressively iterates on it.
That certain people in the Agile community continue to perpetuate the myth that this model is a serious thing that people actually thought was a good idea might be a straw man. But ignoring the rest of the paper is probably good strategy. That one page is a useful starting model for them, too. But they really woudln't want to call attention to any other page of the paper. The rest of the pages are too full of hard-won observations that speak to why Scrum seems to work out so poorly in practice for large, multi-team projects.