12 ms·

The Waterfall Model was a straw man argument from the beginning (2015)

163 points by ern 2y ago

ggm 2y ago
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.
- anonzzzies 2y ago
  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.
  - piva00 2y ago
    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).
- bryanlarsen 2y ago
  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.
  - harshitaneja 2y ago
    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.
  - mathw 2y ago
    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.
turtleyacht 2y ago
Link to Dr. Royce's paper, Managing the Development of Large Software Systems (1970): https://www.praxisframework.org/files/royce1970.pdf https://www.praxisframework.org/files/royce1970.pdf
Tor3 2y ago
"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.
- 2OEH8eoCRo0 2y ago
  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.
  - datavirtue 2y ago
    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.
  - abakker 2y ago
    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.
    - j-a-a-p 2y ago
      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.
fzeindl 2y ago
What is less known is that the author of the waterfall model Winston W. Royce recommended doing the entire process TWICE: https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/ 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.
- 2OEH8eoCRo0 2y ago
  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.
- oneshtein 2y ago
  Many successful rewrites are Waterfalls, regardless of method used for first time.
  - AnimalMuppet 2y ago
    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.
- wrycoder 2y ago
  Here's the Royce paper. Check out page three. [0] https://dl.acm.org/doi/10.5555/41765.41801 https://dl.acm.org/doi/10.5555/41765.41801
trustno2 2y ago
What is TOGAF
- deleted 2y ago
  [deleted]
codeulike 2y ago
Back when Linkedin would let you Endorse people with random skills, Endorsing with "Waterfall" was such a fun diss
ghaff 2y ago
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.
pram 2y ago
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!" Now I don't know what to think!
- bigstrat2003 2y ago
  It not only was real, it still is real. Government in particular loves waterfall.
- bluGill 2y ago
  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)
siva7 2y ago
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.
- datavirtue 2y ago
  Users also expected stability and a lack of regression. Stakeholders simply didn't want or demand a new version every week.
  - bluGill 2y ago
    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.
- Terretta 2y ago
  The entire point of the single paragraph linked by OP is waterfall was a misunderstanding, not a necessity of the era. If you want to see a valid method "back in the 90s", see DSDM: https://en.wikipedia.org/wiki/Dynamic_systems_development_method 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 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.
satisfice 2y ago
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.
rossdavidh 2y ago
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".
- quantadev 2y ago
  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.
  - aidenn0 2y ago
    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.
    - quantadev 2y ago
      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.
Lutzb 2y ago
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.
Zigurd 2y ago
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.
- replyifuagree 2y ago
  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.
  - beastcoast 2y ago
    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.
vegetablepotpie 2y ago
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.
- oneshtein 2y ago
  Waterfalls are good for rewrites, e.g. from Python to Go, because problem/solution territory is explored already.
neilv 2y ago
Two situations that Agile is great for: 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.
- badgersnake 2y ago
  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.
- deleted 2y ago
  [deleted]
- pyrale 2y ago
  > 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.
llm_nerd 2y ago
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.
- mixmastamyk 2y ago
  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.
torginus 2y ago
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'
aa-jv 2y ago
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).
pyrale 2y ago
I fail to follow the logic from the author: - 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.
- datavirtue 2y ago
  Especially in agile.
  - pyrale 2y ago
    I do agree that there is a thriving industry dedicated to finding ways to brand whatever process management currently uses as "agile".
samatman 2y ago
Was it? What if I had a smoking gun? https://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf https://www.product-lifecycle-management.com/download/DOD-ST...
- tracerbulletx 2y ago
  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.
23B1 2y ago
I'm sorry... what? 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.
- tboyd47 2y ago
  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.
  - 23B1 2y ago
    Yeah it's cultural, exactly. 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.
ebiester 2y ago
I dive into this in my blog, "What is your alternative to Agile?" - https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html 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.
jillesvangurp 2y ago
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.
- wrycoder 2y ago
  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.
  - jillesvangurp 2y ago
    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.
gspencley 2y ago
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.
- colechristensen 2y ago
  "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. https://en.wikipedia.org/wiki/Gantt_chart https://en.wikipedia.org/wiki/Gantt_chart
bunderbunder 2y ago
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.
StellarScience 2y ago
2+ decades ago, US Air Force acquisition classes taught exactly this method. I don't recall whether they used the word "waterfall", but they showed the same diagrams and treated software development like massive hardware projects, such as building an F-16: first you write a long requirements document, then generate a voluminous design document, then break the design into a work breakdown structure, farm out component implementation to developers, then finally integrate, test, and ship. It borrowed heavily from the field of Systems Engineering. In my experience it never worked. We were able to achieve success only by secretly ignoring the rules and process and instead developing software in what detractors called a "cowboy" process. When "agile" came out, it changed our lives. We adopted a few new good ideas, but mostly kept working as we had been. But now we could point to this quasi-official "agile process", with tailoring as they recommend. As long as we were following a process, and not being "cowboys", folks seemed satisfied. These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.
- Jtsummers 2y ago
  Acquisitions didn't use Waterfall that I ever saw, until you got to the software specific courses. Then they did, and it was one of several software development lifecycles you were allowed to choose between for projects. Many program offices and project managers selected it because it was pretty, not because it was sensible. > These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past. Circa 2010 (+/- a couple years) USAF also picked up Lean in a big way. But their version of Lean was almost exactly the opposite, in practice, of what was done and described by industry as Lean. A key element of Lean being that you actually let the people doing the work provide feedback and direct improvement efforts. USAF's version had the managers (who never did the work) walk around and observe, then change processes to be "leaner". That is, pure scientific management in the Taylorism style. USAF is a great place for good ideas to get their names reused for old ideas.
opk 2y ago
When I was studying in the late 80s / early 90s, the text books contrasted the "old" waterfall approach with the more "modern" iterative approach. That was long before Agile or whatever had been invented and recognised that there needed to be a feedback loop. Trying to promote agile/scrum/xp/whatever by attacking waterfall is a straw man argument in my view because it is not comparing against what came before. That's not to say that clueless managers don't still like to reinvent and impose what is essentially waterfall.
ineedasername 2y ago
The author is fortunate to have so few encounters with this IRL because there is a world of difference between “I have never seen a book propose this” and encountering it in practice. To my misfortune I have been involved in multiple ERP implementations where such require heavy customization & development of custom & bolt-on modules. This model wasn’t explicitly presented in this visual style but it was the approach. Requirements were set nearly in stone even as business needs changed during a multi-year project. The result was systems people avoided using, creating shadow systems or surprising IT with “we bought this and need it integrated”.
shahzaibmushtaq 2y ago
The Waterfall Model had its time and piece of the pie (still has in the form of modified Waterfall models) at the beginning of the software development era when software was complex in nature. Therefore, time spent early reduces costs at later stages e.g., a problem found in early stages is cheaper to fix than later in the process because the software has to be embedded in the hardware - no software updates. We all know that it's not easy to find a good software engineer back then, or a knowledge center (like we do now) to get help from. If one team member leaves in the middle of an ongoing project for whatever reason, good documentation must be there for the new member to get a complete understanding of what's going on. The Waterfall Model was never perfect, and Royce never claims it is. Instead, he himself pointed out major flaws such as testing only happened at the end of the process. One thing I want to add is that Royce didn't use the term Waterfall but he said something like downstream. And he was right because we all know that speed of water is very fast but in this model it's too slow. Perhaps that's why he proposed modified versions of the original Water fall model https://www.researchgate.net/figure/Royces-modifications-of-the-original-waterfall-model-2_fig2_267711880 https://www.researchgate.net/figure/Royces-modifications-of-...
moandcompany 2y ago
I wish that discussions of Waterfall, "Agile," etc, and systems/software development methodologies would spend more time considering the motivations and rational reasons for why the process approach was created. The practice of systems and software engineering has existed longer than many of us have been professionals, and in many cases longer than many of us have been alive. The "Waterfall" systems (or software) development model was developed to reduce the likelihood and impact of requirements or specification changes over its development lifecycle. Likelihood and impact are elements of "risk," and the process can be seen as part of risk management. Rephrased, the Waterfall development methodology as a process was intended to help ensure that the system being developed (and delivered) was the correct solution (i.e. "valid") for the problems considered, and that the process of getting there would have the best known and acceptable costs. With any instance of a development process, there are risks of: Not getting the requirements or specifications correct (i.e. Failing to understand or solve the actual problem), Completion delays due to time spent on re-design or re-implementation from revisions to requirements or specifications, Completion cost overruns (i.e. delays) due to re-design or re-implementation, etc. The Waterfall process approach was eventually codified into things like MIL-STD-498 (https://en.wikipedia.org/wiki/MIL-STD-498 https://en.wikipedia.org/wiki/MIL-STD-498) for software development. Waterfall is not specific to software development, and some lessons ingrained in the process came from disciplines where the cost of misunderstood requirements, changing requirements, or incorrect specifications are higher. Examples could include the design of a bridge, building, space launch vehicle, network communications systems, etc. In these cases, the further you go into development, the more costly ambiguity and/or errors in understanding the problem become. Unfortunately, as seen with many "processes," strict adherence to process or ritual without understanding or sanity checking what is being practiced against the rationale or purpose for those processes leads to poor outcomes. This is what the authors of the Agile Manifesto were responding to, and ironically the negative pattern of adherence to process without understanding why has replicated itself with modern practice of "agile" -- That is a human behavior and organizational culture problem.
cbsmith 2y ago
I love realizing that I'm old enough that people think that practices that were the norm at the start of my career don't seem credible even a decade ago.
steeeeeve 2y ago
All project management is terrible when you are following it blindly and have no understanding of what it takes to succeed. Waterfall works when it's done right in the right environment. It's a nightmare when it's not. Agile works when it's done right in the right environment. It's a nightmare when it's not. Having a good project manager who understands what it takes to succeed from a management/executive perspective and who understands how to keep engineers both productive and happy is priceless. During the waterfall days, you would run into managers who would gannt everything and harass people into meeting deadlines for whatever would solve the 8 word description of the item on the chart. These days, you run into managers who are happy to distribute a jira ticket to resolve anyones gripe. And then there are the thoughtful ones who understand priorities, factors for success, and how to set reasonable expectations on both sides of the table (for the techies and non-techies) In the end, it's not the process you follow, it's the results that matter.
- Hasu 2y ago
  > In the end, it's not the process you follow, it's the results that matter. I was nodding along with this post up until this last sentence. Yes, the results are what matter, but process is what drives the results. It is thus critical to the success of a project to ensure that the process is appropriate. For example, the entire purpose of agile is to have short iteration cycles where you deliver to customers and get feedback before starting the next cycle. If you have a product where you cannot get feedback, agile is a bad solution! You will deliver every two weeks - and then continue to do what you would have done anyway. That makes all the agile ceremonies quite the waste of time. Conversely, if you ARE getting feedback regularly it's insane to do waterfall when you're two weeks into a 6 month project, and the customer doesn't like what you're showing them. This can get a lot more detailed at the micro-level for managing process on teams - there are tradeoffs between developer happiness, speed, quality, visibility, and many other axes that process can adjust, and a team that is set up with good process will be set up to execute better than one that isn't. I tend to be someone that is perceived to "hate process", but I don't, I hate bad process that is counterproductive to execution and achieving results.
marcosdumay 2y ago
Yes, the person that invented that name did personally say he created it as a strawman and never saw it applied anywhere. At the same time, the waterfall model was the standard model for contracting software in large organizations until around the 10s (yep, 2010s), usually mandated by all kinds of compliance rules.
survivedurcode 2y ago
Just because there was research from 1970 (as there was in subsequent years) showing that big design up front is a bad idea doesn’t mean that waterfall is a straw man argument. It is probably necessary when you are shipping code with extremely high costs of operation, where mistakes are extremely expensive (i.e. missiles, space shuttles). I imagine automotive ECU software is probably in that category. The software industry has ignored research from 1970s and on and continues to ignore it today. Look at the microservices craze. It’s another way that big-design up-front has been brought back.
sevensor 2y ago
My most successful project management experience ever worked like this: we had a massive Gantt chart showing all of the work we had planned. I added and removed rows daily, updated expected completion dates, and generally rearranged the whole thing. The one thing that never changed was anticipated delivery date. Every week I sent the CTO a report with a snapshot and an explanation of what changed and why. I expected to get yelled at more than once, but he was happy with the sense of control, and the developers enjoyed the flexibility. It was exhausting and I’m glad I’m not doing project management in my current role.
moominpapa 2y ago
[flagged]
junto 2y ago
Almost twenty years ago I worked on a project where an external unnamed “big four consultancy” had written a very long document titled “statement of works” that had about 130 pages. It described a LOB application for a corporate customer in minute detail. Every form was described with the order of input elements, fonts and font sizes to be used, grouping of fields, you name it, it was there. We just followed the instructions exactly and after 15 months we delivered the finished application. These kinds of projects did exist but the specification and requirements phase was long and expensive. However it required the client to take the time to understand their current business processes and more importantly what they should be and how they wanted them to work. It was one of the most mundanely boring projects I ever worked on.
stevenalowe 2y ago
Gated development cycles were/are common, regardless of what you call them. If the target is not moving too fast, the process can work. If computer time is vastly more expensive than programmer time, working 'offline' writing/checking specs is time well-spent. If you take the standard SDLC steps, apply them to the smallest useful piece of functionality, replace written specs with automated tests, you get a single-piece flow model which strongly resembles agile practices (but says nothing about agile philosophy).
nomel 2y ago
I personally can't comprehend building software with the waterfall method. I always do a reverse waterfall: build the fundamentals at the bottom. They are the non-negotiable "truths" of the problem, representing something close to the minimal complexity. Then, tie them together to work towards the relatively mushy end goal, with the abstractions being much more obvious as you work your way up, with a few "shifts" where higher level abstractions may pop out and collapse things into simpler pieces as you go up. I would consider the GUI being one of those "truths".
fermigier 2y ago
In French, we call it "Le cycle en V" and we think it's beautiful.
snapetom 2y ago
My first job in development was at a lending division at a bank. After that, I was at a large health insurance company. (1999-2005) Waterfall certainly did exist and it got even worse at the health insurance company. My official title was "Application Developer" but I spent about 60% of my time filling out reams of paper that got passed around in meetings with everyone under the sun that took another 20% of my time. The first time a startup recruited me and described how they worked, I jumped on that mainly because I'd actually be coding.
worik 2y ago
I was explicitly taught the waterfall model in 1991 at a university computer science course I had to work out the problems myself
ang_cire 2y ago
Every waterfall project was actually spiral or hybrid.
atribecalledqst 2y ago
Reading this thread is bumming me out because it's made me realized my company USED TO have a good fusion between 'waterfall' and 'agile'. The requirements development phase, development, and testing phases were all very flexible and had feedback mechanisms as we gradually figured out The Right Way to get the thing to work. Systems, software, and testing all worked in close concert so that software developers could find problems or gaps in requirements, as could testers. And of course there was a strong feedback loop between software & test. Meetings were weekly and people reached out to each other as needed outside of that. A daily standup was usually a sign that something was wrong. In recent years we've moved to cargo-cult capital-A Agile, so we've basically traded our flexible process for a LOT more meeting overhead and pretty much a negative gain in efficiency. We spend significant portions of meetings talking about process which was never a problem in the past. All because we didn't fit some predefined one-size-fits-all framework... sad! (and of course the REALLY dumb thing, is that we're still often tied to a delivery schedule of 1 or 2 builds a year, with customer selloff testing - so the external process we fit into is still 'waterfall-y') e; I guess one thing I neglected to mention here is schedule. We usually never had issues with schedule, our timelines were generous enough that even if we underestimated the complexity of something we could still make the delivery date. (admittedly there would sometimes be crunch periods in the last few weeks before delivery)
bulletmarker 2y ago
If you follow the waterfall process faithfully then you guarantee mediocrity in what you produce.
readthenotes1 2y ago
It would have been better if the author had used the flow diagram from the original waterfall paper that showed the backflows.
mont_tag 2y ago
It was not a straw man. I've seen it specified in contracts. I've seen audit teams sent in to verify an SDLC (system development life cycle). Arthur Andersen (now Andersen consulting) had it formalized in their "Method 1" system development approach. Any semblance of agile was met with hostility. You were labeled a "cowboy programmer" or "hobbyist programmer" if you dared start with code instead of specification and approved plan. Also, it is easy to forget those "rules" weren't wrong. People were coding in non-agile languages. Version control tools had strict checkout and locking. Project communication was in the form of rows of three ring binders -- everytime you added or changed a function, you marked up the existing doc page and a secretary retyped it with carbon paper (for a subject book, title book, and subsystem book). Changed to requirements were very expensive, so the whole system was designed to get full buy in a once. Consider that even now in this "age of enlightenment", we take a waterfall approach in nonsoftware projects simply because changes are expensive. If you're having a custom home built, you need to make a lot of decisions early. You're charged heavily if you want to change the spec during construction.
black_13 2y ago
The evolution of software development methodologies, from waterfall to agile and beyond, reflects broader shifts in business models and power dynamics within the tech industry. As companies have moved from traditional profit-driven models to ones focused on stock value and rapid growth, development practices have adapted to prioritize speed and flexibility over long-term stability. This shift has coincided with a change in the role and autonomy of engineers, who once had more control over the development process but now often find themselves navigating business pressures and shortened cycles. The debate over methodologies like waterfall versus agile is thus not merely about technical approaches, but about fundamental changes in how value is created, how engineering talent is utilized, and how software projects are controlled and prioritized. This context helps explain the generational divide in perspectives on these issues, with older engineers potentially valuing stable, well-engineered systems, while younger developers may be more accepting of rapid iteration and business-driven development cycles.
RecycledEle 2y ago
Waterfall makes sense if contracts and lawyers are involved. Waterfall makes sense if national security is at stake. Waterfall's downsides are reduced by having competent people write fewer errors into the specification. There are defense contractors that once used waterfall.
RandomThoughts3 2y ago
Hate me for it but iterated waterfall was the best time of my life and I still think it’s far superior to agile. My first job, we actually took time to think about the system design. Being forced to get proper quality insurance manager approval before moving to build meant you couldn’t cut corners and having a proper testing team running a full qualification on what was produced meant things were always tested in depth from the point of view of a user before release. Every parts of the system were properly documented and we had proper tooling allowing us to go from system design to component design all the way to a specific version test results which was incredibly nice when trying to understand what was happening. Everyone was working on multiple components being in different phase at the same time so there was no downtime and you would just restart design of a new version as soon as you got back feedbacks from qualification. I have probably never been as productive in my life and everything was working like a well oiled machine. Every agile project I have ever worked on is a complete mess.
peterashford 2y ago
To me, much of what has been said about Waterfall is a strawman. Firstly, the idea that no-one ever iterated doing Waterfall is just not true. The idea that Gantt charts are some sign of evil is, IMO, misplaced. Like all tools, they can be used poorly - but so long as you keep them regularly updated, they can be quite powerful. In a prior job, another dev - a lovely guy - claimed that Waterfall projects always failed, which was news to me as I'd worked on dozens of them and none had failed. I feel like the take home message is perhaps that we tend to mythologize processes and make them into caricatures of reality. The actual truth is always more complex and more nuanced. Which, ironically, I think is kinda the point of the Agile Manifesto. At any rate, I certainly feel that most people I've ever met who think that "doing scrum" is Agile are less agile than the people I used to work with doing Waterfall. It's not about processes, its about people and interactions.
nickm12 2y ago
It doesn't matter what you call your process, you are setting yourself up for failure if you don't (1) clearly understand the problem you are trying to solve (2) think holistically about your solution (and its risks) before you start building it. This is true whether you are making a small bug fix or enhancement, building a new system from scratch, or anything in between. Processes are tools for doing these things, but they can also sometimes obscure when they are being done poorly and in some cases don't allow them to be done well—there are some places where you have to go deep on understanding the problem or deep on validating the solution and the process works against it.
shantnutiwari 2y ago
Whaaaat? Even 10-12 years ago Ive worked for companies that used waterfall. Most hardware/embedded companies do, because it works for hardware. The problem arises when they try to use it for software too (though embedded companies have gotten better last 5-7 years)
dennis_jeeves2 2y ago
Enlighten me - what is the difference between a functioning ( milestones, sufficient interaction with end user, frequent monitoring of scope creep, iterative etc.) waterfall and agile? I see no difference. I have read the agile manifesto in the distance post and nothing seems to stand out.

163 points by ern 2y ago

ggm 2y ago

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.

anonzzzies 2y ago
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.
- piva00 2y ago
  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).
bryanlarsen 2y ago
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.
- harshitaneja 2y ago
  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.
- mathw 2y ago
  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.

turtleyacht 2y ago

Link to Dr. Royce's paper, Managing the Development of Large Software Systems (1970): https://www.praxisframework.org/files/royce1970.pdf https://www.praxisframework.org/files/royce1970.pdf

Tor3 2y ago

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

2OEH8eoCRo0 2y ago
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.
- datavirtue 2y ago
  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.
- abakker 2y ago
  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.
  - j-a-a-p 2y ago
    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.

fzeindl 2y ago

What is less known is that the author of the waterfall model Winston W. Royce recommended doing the entire process TWICE: https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/ 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.

2OEH8eoCRo0 2y ago
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.
oneshtein 2y ago
Many successful rewrites are Waterfalls, regardless of method used for first time.
- AnimalMuppet 2y ago
  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.
wrycoder 2y ago
Here's the Royce paper. Check out page three. [0] https://dl.acm.org/doi/10.5555/41765.41801 https://dl.acm.org/doi/10.5555/41765.41801

trustno2 2y ago

What is TOGAF

deleted 2y ago
[deleted]

codeulike 2y ago

Back when Linkedin would let you Endorse people with random skills, Endorsing with "Waterfall" was such a fun diss

ghaff 2y ago

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.

pram 2y ago

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!" Now I don't know what to think!

bigstrat2003 2y ago
It not only was real, it still is real. Government in particular loves waterfall.
bluGill 2y ago
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)

siva7 2y ago

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.

datavirtue 2y ago
Users also expected stability and a lack of regression. Stakeholders simply didn't want or demand a new version every week.
- bluGill 2y ago
  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.
Terretta 2y ago
The entire point of the single paragraph linked by OP is waterfall was a misunderstanding, not a necessity of the era. If you want to see a valid method "back in the 90s", see DSDM: https://en.wikipedia.org/wiki/Dynamic_systems_development_method 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 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.

satisfice 2y ago

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.

rossdavidh 2y ago

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

quantadev 2y ago
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.
- aidenn0 2y ago
  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.
  - quantadev 2y ago
    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.

Lutzb 2y ago

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.

Zigurd 2y ago

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.

replyifuagree 2y ago
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.
- beastcoast 2y ago
  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.

vegetablepotpie 2y ago

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.

oneshtein 2y ago
Waterfalls are good for rewrites, e.g. from Python to Go, because problem/solution territory is explored already.

neilv 2y ago

Two situations that Agile is great for: 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.

badgersnake 2y ago
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.
deleted 2y ago
[deleted]
pyrale 2y ago
> 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.

llm_nerd 2y ago

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.

mixmastamyk 2y ago
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.

torginus 2y ago

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'

aa-jv 2y ago

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

pyrale 2y ago

I fail to follow the logic from the author: - 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.

datavirtue 2y ago
Especially in agile.
- pyrale 2y ago
  I do agree that there is a thriving industry dedicated to finding ways to brand whatever process management currently uses as "agile".

samatman 2y ago

Was it? What if I had a smoking gun? https://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf https://www.product-lifecycle-management.com/download/DOD-ST...

tracerbulletx 2y ago
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.

23B1 2y ago

I'm sorry... what? 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.

tboyd47 2y ago
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.
- 23B1 2y ago
  Yeah it's cultural, exactly. 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.

ebiester 2y ago

I dive into this in my blog, "What is your alternative to Agile?" - https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html 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.

jillesvangurp 2y ago

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.

wrycoder 2y ago
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.
- jillesvangurp 2y ago
  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.

gspencley 2y ago

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.

colechristensen 2y ago
"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. https://en.wikipedia.org/wiki/Gantt_chart https://en.wikipedia.org/wiki/Gantt_chart

bunderbunder 2y ago

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.

StellarScience 2y ago

2+ decades ago, US Air Force acquisition classes taught exactly this method. I don't recall whether they used the word "waterfall", but they showed the same diagrams and treated software development like massive hardware projects, such as building an F-16: first you write a long requirements document, then generate a voluminous design document, then break the design into a work breakdown structure, farm out component implementation to developers, then finally integrate, test, and ship. It borrowed heavily from the field of Systems Engineering. In my experience it never worked. We were able to achieve success only by secretly ignoring the rules and process and instead developing software in what detractors called a "cowboy" process. When "agile" came out, it changed our lives. We adopted a few new good ideas, but mostly kept working as we had been. But now we could point to this quasi-official "agile process", with tailoring as they recommend. As long as we were following a process, and not being "cowboys", folks seemed satisfied. These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.

Jtsummers 2y ago
Acquisitions didn't use Waterfall that I ever saw, until you got to the software specific courses. Then they did, and it was one of several software development lifecycles you were allowed to choose between for projects. Many program offices and project managers selected it because it was pretty, not because it was sensible. > These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past. Circa 2010 (+/- a couple years) USAF also picked up Lean in a big way. But their version of Lean was almost exactly the opposite, in practice, of what was done and described by industry as Lean. A key element of Lean being that you actually let the people doing the work provide feedback and direct improvement efforts. USAF's version had the managers (who never did the work) walk around and observe, then change processes to be "leaner". That is, pure scientific management in the Taylorism style. USAF is a great place for good ideas to get their names reused for old ideas.

opk 2y ago

When I was studying in the late 80s / early 90s, the text books contrasted the "old" waterfall approach with the more "modern" iterative approach. That was long before Agile or whatever had been invented and recognised that there needed to be a feedback loop. Trying to promote agile/scrum/xp/whatever by attacking waterfall is a straw man argument in my view because it is not comparing against what came before. That's not to say that clueless managers don't still like to reinvent and impose what is essentially waterfall.

ineedasername 2y ago

The author is fortunate to have so few encounters with this IRL because there is a world of difference between “I have never seen a book propose this” and encountering it in practice. To my misfortune I have been involved in multiple ERP implementations where such require heavy customization & development of custom & bolt-on modules. This model wasn’t explicitly presented in this visual style but it was the approach. Requirements were set nearly in stone even as business needs changed during a multi-year project. The result was systems people avoided using, creating shadow systems or surprising IT with “we bought this and need it integrated”.

shahzaibmushtaq 2y ago

The Waterfall Model had its time and piece of the pie (still has in the form of modified Waterfall models) at the beginning of the software development era when software was complex in nature. Therefore, time spent early reduces costs at later stages e.g., a problem found in early stages is cheaper to fix than later in the process because the software has to be embedded in the hardware - no software updates. We all know that it's not easy to find a good software engineer back then, or a knowledge center (like we do now) to get help from. If one team member leaves in the middle of an ongoing project for whatever reason, good documentation must be there for the new member to get a complete understanding of what's going on. The Waterfall Model was never perfect, and Royce never claims it is. Instead, he himself pointed out major flaws such as testing only happened at the end of the process. One thing I want to add is that Royce didn't use the term Waterfall but he said something like downstream. And he was right because we all know that speed of water is very fast but in this model it's too slow. Perhaps that's why he proposed modified versions of the original Water fall model https://www.researchgate.net/figure/Royces-modifications-of-the-original-waterfall-model-2_fig2_267711880 https://www.researchgate.net/figure/Royces-modifications-of-...

moandcompany 2y ago

I wish that discussions of Waterfall, "Agile," etc, and systems/software development methodologies would spend more time considering the motivations and rational reasons for why the process approach was created. The practice of systems and software engineering has existed longer than many of us have been professionals, and in many cases longer than many of us have been alive. The "Waterfall" systems (or software) development model was developed to reduce the likelihood and impact of requirements or specification changes over its development lifecycle. Likelihood and impact are elements of "risk," and the process can be seen as part of risk management. Rephrased, the Waterfall development methodology as a process was intended to help ensure that the system being developed (and delivered) was the correct solution (i.e. "valid") for the problems considered, and that the process of getting there would have the best known and acceptable costs. With any instance of a development process, there are risks of: Not getting the requirements or specifications correct (i.e. Failing to understand or solve the actual problem), Completion delays due to time spent on re-design or re-implementation from revisions to requirements or specifications, Completion cost overruns (i.e. delays) due to re-design or re-implementation, etc. The Waterfall process approach was eventually codified into things like MIL-STD-498 (https://en.wikipedia.org/wiki/MIL-STD-498 https://en.wikipedia.org/wiki/MIL-STD-498) for software development. Waterfall is not specific to software development, and some lessons ingrained in the process came from disciplines where the cost of misunderstood requirements, changing requirements, or incorrect specifications are higher. Examples could include the design of a bridge, building, space launch vehicle, network communications systems, etc. In these cases, the further you go into development, the more costly ambiguity and/or errors in understanding the problem become. Unfortunately, as seen with many "processes," strict adherence to process or ritual without understanding or sanity checking what is being practiced against the rationale or purpose for those processes leads to poor outcomes. This is what the authors of the Agile Manifesto were responding to, and ironically the negative pattern of adherence to process without understanding why has replicated itself with modern practice of "agile" -- That is a human behavior and organizational culture problem.

cbsmith 2y ago

I love realizing that I'm old enough that people think that practices that were the norm at the start of my career don't seem credible even a decade ago.

steeeeeve 2y ago

All project management is terrible when you are following it blindly and have no understanding of what it takes to succeed. Waterfall works when it's done right in the right environment. It's a nightmare when it's not. Agile works when it's done right in the right environment. It's a nightmare when it's not. Having a good project manager who understands what it takes to succeed from a management/executive perspective and who understands how to keep engineers both productive and happy is priceless. During the waterfall days, you would run into managers who would gannt everything and harass people into meeting deadlines for whatever would solve the 8 word description of the item on the chart. These days, you run into managers who are happy to distribute a jira ticket to resolve anyones gripe. And then there are the thoughtful ones who understand priorities, factors for success, and how to set reasonable expectations on both sides of the table (for the techies and non-techies) In the end, it's not the process you follow, it's the results that matter.

Hasu 2y ago
> In the end, it's not the process you follow, it's the results that matter. I was nodding along with this post up until this last sentence. Yes, the results are what matter, but process is what drives the results. It is thus critical to the success of a project to ensure that the process is appropriate. For example, the entire purpose of agile is to have short iteration cycles where you deliver to customers and get feedback before starting the next cycle. If you have a product where you cannot get feedback, agile is a bad solution! You will deliver every two weeks - and then continue to do what you would have done anyway. That makes all the agile ceremonies quite the waste of time. Conversely, if you ARE getting feedback regularly it's insane to do waterfall when you're two weeks into a 6 month project, and the customer doesn't like what you're showing them. This can get a lot more detailed at the micro-level for managing process on teams - there are tradeoffs between developer happiness, speed, quality, visibility, and many other axes that process can adjust, and a team that is set up with good process will be set up to execute better than one that isn't. I tend to be someone that is perceived to "hate process", but I don't, I hate bad process that is counterproductive to execution and achieving results.

marcosdumay 2y ago

Yes, the person that invented that name did personally say he created it as a strawman and never saw it applied anywhere. At the same time, the waterfall model was the standard model for contracting software in large organizations until around the 10s (yep, 2010s), usually mandated by all kinds of compliance rules.

survivedurcode 2y ago

Just because there was research from 1970 (as there was in subsequent years) showing that big design up front is a bad idea doesn’t mean that waterfall is a straw man argument. It is probably necessary when you are shipping code with extremely high costs of operation, where mistakes are extremely expensive (i.e. missiles, space shuttles). I imagine automotive ECU software is probably in that category. The software industry has ignored research from 1970s and on and continues to ignore it today. Look at the microservices craze. It’s another way that big-design up-front has been brought back.

sevensor 2y ago

My most successful project management experience ever worked like this: we had a massive Gantt chart showing all of the work we had planned. I added and removed rows daily, updated expected completion dates, and generally rearranged the whole thing. The one thing that never changed was anticipated delivery date. Every week I sent the CTO a report with a snapshot and an explanation of what changed and why. I expected to get yelled at more than once, but he was happy with the sense of control, and the developers enjoyed the flexibility. It was exhausting and I’m glad I’m not doing project management in my current role.

moominpapa 2y ago

[flagged]

junto 2y ago

Almost twenty years ago I worked on a project where an external unnamed “big four consultancy” had written a very long document titled “statement of works” that had about 130 pages. It described a LOB application for a corporate customer in minute detail. Every form was described with the order of input elements, fonts and font sizes to be used, grouping of fields, you name it, it was there. We just followed the instructions exactly and after 15 months we delivered the finished application. These kinds of projects did exist but the specification and requirements phase was long and expensive. However it required the client to take the time to understand their current business processes and more importantly what they should be and how they wanted them to work. It was one of the most mundanely boring projects I ever worked on.

stevenalowe 2y ago

Gated development cycles were/are common, regardless of what you call them. If the target is not moving too fast, the process can work. If computer time is vastly more expensive than programmer time, working 'offline' writing/checking specs is time well-spent. If you take the standard SDLC steps, apply them to the smallest useful piece of functionality, replace written specs with automated tests, you get a single-piece flow model which strongly resembles agile practices (but says nothing about agile philosophy).

nomel 2y ago

I personally can't comprehend building software with the waterfall method. I always do a reverse waterfall: build the fundamentals at the bottom. They are the non-negotiable "truths" of the problem, representing something close to the minimal complexity. Then, tie them together to work towards the relatively mushy end goal, with the abstractions being much more obvious as you work your way up, with a few "shifts" where higher level abstractions may pop out and collapse things into simpler pieces as you go up. I would consider the GUI being one of those "truths".

fermigier 2y ago

In French, we call it "Le cycle en V" and we think it's beautiful.

snapetom 2y ago

My first job in development was at a lending division at a bank. After that, I was at a large health insurance company. (1999-2005) Waterfall certainly did exist and it got even worse at the health insurance company. My official title was "Application Developer" but I spent about 60% of my time filling out reams of paper that got passed around in meetings with everyone under the sun that took another 20% of my time. The first time a startup recruited me and described how they worked, I jumped on that mainly because I'd actually be coding.

worik 2y ago

I was explicitly taught the waterfall model in 1991 at a university computer science course I had to work out the problems myself

ang_cire 2y ago

Every waterfall project was actually spiral or hybrid.

atribecalledqst 2y ago

Reading this thread is bumming me out because it's made me realized my company USED TO have a good fusion between 'waterfall' and 'agile'. The requirements development phase, development, and testing phases were all very flexible and had feedback mechanisms as we gradually figured out The Right Way to get the thing to work. Systems, software, and testing all worked in close concert so that software developers could find problems or gaps in requirements, as could testers. And of course there was a strong feedback loop between software & test. Meetings were weekly and people reached out to each other as needed outside of that. A daily standup was usually a sign that something was wrong. In recent years we've moved to cargo-cult capital-A Agile, so we've basically traded our flexible process for a LOT more meeting overhead and pretty much a negative gain in efficiency. We spend significant portions of meetings talking about process which was never a problem in the past. All because we didn't fit some predefined one-size-fits-all framework... sad! (and of course the REALLY dumb thing, is that we're still often tied to a delivery schedule of 1 or 2 builds a year, with customer selloff testing - so the external process we fit into is still 'waterfall-y') e; I guess one thing I neglected to mention here is schedule. We usually never had issues with schedule, our timelines were generous enough that even if we underestimated the complexity of something we could still make the delivery date. (admittedly there would sometimes be crunch periods in the last few weeks before delivery)

bulletmarker 2y ago

If you follow the waterfall process faithfully then you guarantee mediocrity in what you produce.

readthenotes1 2y ago

It would have been better if the author had used the flow diagram from the original waterfall paper that showed the backflows.

mont_tag 2y ago

It was not a straw man. I've seen it specified in contracts. I've seen audit teams sent in to verify an SDLC (system development life cycle). Arthur Andersen (now Andersen consulting) had it formalized in their "Method 1" system development approach. Any semblance of agile was met with hostility. You were labeled a "cowboy programmer" or "hobbyist programmer" if you dared start with code instead of specification and approved plan. Also, it is easy to forget those "rules" weren't wrong. People were coding in non-agile languages. Version control tools had strict checkout and locking. Project communication was in the form of rows of three ring binders -- everytime you added or changed a function, you marked up the existing doc page and a secretary retyped it with carbon paper (for a subject book, title book, and subsystem book). Changed to requirements were very expensive, so the whole system was designed to get full buy in a once. Consider that even now in this "age of enlightenment", we take a waterfall approach in nonsoftware projects simply because changes are expensive. If you're having a custom home built, you need to make a lot of decisions early. You're charged heavily if you want to change the spec during construction.

black_13 2y ago

The evolution of software development methodologies, from waterfall to agile and beyond, reflects broader shifts in business models and power dynamics within the tech industry. As companies have moved from traditional profit-driven models to ones focused on stock value and rapid growth, development practices have adapted to prioritize speed and flexibility over long-term stability. This shift has coincided with a change in the role and autonomy of engineers, who once had more control over the development process but now often find themselves navigating business pressures and shortened cycles. The debate over methodologies like waterfall versus agile is thus not merely about technical approaches, but about fundamental changes in how value is created, how engineering talent is utilized, and how software projects are controlled and prioritized. This context helps explain the generational divide in perspectives on these issues, with older engineers potentially valuing stable, well-engineered systems, while younger developers may be more accepting of rapid iteration and business-driven development cycles.

RecycledEle 2y ago

Waterfall makes sense if contracts and lawyers are involved. Waterfall makes sense if national security is at stake. Waterfall's downsides are reduced by having competent people write fewer errors into the specification. There are defense contractors that once used waterfall.

RandomThoughts3 2y ago

Hate me for it but iterated waterfall was the best time of my life and I still think it’s far superior to agile. My first job, we actually took time to think about the system design. Being forced to get proper quality insurance manager approval before moving to build meant you couldn’t cut corners and having a proper testing team running a full qualification on what was produced meant things were always tested in depth from the point of view of a user before release. Every parts of the system were properly documented and we had proper tooling allowing us to go from system design to component design all the way to a specific version test results which was incredibly nice when trying to understand what was happening. Everyone was working on multiple components being in different phase at the same time so there was no downtime and you would just restart design of a new version as soon as you got back feedbacks from qualification. I have probably never been as productive in my life and everything was working like a well oiled machine. Every agile project I have ever worked on is a complete mess.

peterashford 2y ago

To me, much of what has been said about Waterfall is a strawman. Firstly, the idea that no-one ever iterated doing Waterfall is just not true. The idea that Gantt charts are some sign of evil is, IMO, misplaced. Like all tools, they can be used poorly - but so long as you keep them regularly updated, they can be quite powerful. In a prior job, another dev - a lovely guy - claimed that Waterfall projects always failed, which was news to me as I'd worked on dozens of them and none had failed. I feel like the take home message is perhaps that we tend to mythologize processes and make them into caricatures of reality. The actual truth is always more complex and more nuanced. Which, ironically, I think is kinda the point of the Agile Manifesto. At any rate, I certainly feel that most people I've ever met who think that "doing scrum" is Agile are less agile than the people I used to work with doing Waterfall. It's not about processes, its about people and interactions.

nickm12 2y ago

It doesn't matter what you call your process, you are setting yourself up for failure if you don't (1) clearly understand the problem you are trying to solve (2) think holistically about your solution (and its risks) before you start building it. This is true whether you are making a small bug fix or enhancement, building a new system from scratch, or anything in between. Processes are tools for doing these things, but they can also sometimes obscure when they are being done poorly and in some cases don't allow them to be done well—there are some places where you have to go deep on understanding the problem or deep on validating the solution and the process works against it.

shantnutiwari 2y ago

Whaaaat? Even 10-12 years ago Ive worked for companies that used waterfall. Most hardware/embedded companies do, because it works for hardware. The problem arises when they try to use it for software too (though embedded companies have gotten better last 5-7 years)

dennis_jeeves2 2y ago

Enlighten me - what is the difference between a functioning ( milestones, sufficient interaction with end user, frequent monitoring of scope creep, iterative etc.) waterfall and agile? I see no difference. I have read the agile manifesto in the distance post and nothing seems to stand out.