6 ms·

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

• 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.
      • abakker 2y ago
        there's probably a rational category based on the size/complexity of the data model. I get the sense that very complicated data models are what really ruins the agile approach for complex environments.
• morkalork 2y ago
  How much do you think it was an artifact of the time? Agile relies on it being fast/cheap/easy to ship and deploy incremental changes. I have a hard time believing that to be the case in the 80s. When planning and designing on paper is cheap in comparison, it makes sense to me that is the development method people used.
  • makeitdouble 2y ago
    I think it was more about the corporate culture which dictated that people had a plan and stick to it. It's still the case in many trades. You don't build a house or a bridge the Agile way for instance. IMHO Agile got a lot more prevalent because the planning phase became more and more onerous to have any reliability, and management was tired of paying upfront for it. I steady they could get a more regular billing (in particular when dealing with consulting companies) with reports of stuff allegedly shipped, instead of six months of "we're planning very hard, just trust us". Whether the end result matched what they needed/wanted to build being another story. I know many companies that had an official Waterfall cycle, while actually working on something more granularly shipped with many phases of prototyping. And they didn't move to Agile either, just stopped calling their process anything and went on doing whatever felt right.
    • benfortuna 2y ago
      >It's still the case in many trades. You don't build a house or a bridge the Agile way for instance. Looking at how some houses are built these days, a case could be made for Agile over "do your best, silicone the rest".
  • detourdog 2y ago
    I find agile passive aggressive because the consensus is built under duress. I prefer a well reasoned approach. I can understand agile process in between waterfall milestones. I can even support an agile process to create waterfall process.
    • datavirtue 2y ago
• JohnFen 2y ago
  > I've been on software development projects (the final product would be source delivered to the customer) where the waterfall model was explicitly specified On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common.
  • convolvatron 2y ago
    I have certainly seen projects that started by planning everything out. High level designs, milestones, integration dates. Giant GANNT charts. But by the second quarter everyone was pretty much just redrawing the whole map, getting what they could running as early as possible and throwing things off the bus.
    • Supermancho 2y ago
      I still see it today, in various projects.
  • jerf 2y ago
    If you consider this not as a binary choice, but "waterfall" on one end meaning that the whole design process has basically no feedback, and "agile manifesto agile" (not scrum or any other calcification of the process, but the true chaotic "just depend on your engineers to be smart" process), it's probably true there has never been a "true", all-the-way-to-one-end Waterfall design that went for multiple years, because such a thing is essentially impossible. It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan. I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation. And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
• torginus 2y ago
  Honestly I could see it working in projects with inherently high complexity and/or set timelines like operating systems, compilers, video games. There's often a clear goal in these cases, and there's no 'minimum valuable product' you can quickly iterate on.
  • benfortuna 2y ago
    The requirements and design phases can/did often work very well. It's what comes after that derails the process. When you spend more time trying to update your design to match the implementation (via change requests) than implementing you start to wonder if there's maybe a better way..
• AnimalMuppet 2y ago
  I think waterfall and waterfall-ish development is more prevalent in government contracting. You aren't building for yourself, you're building for a single external customer, and you have to build both the functionality and the interfaces that they want. And I note that government contracting was probably a bigger fraction of all software engineering in the 1980s than it is today. (Still more in the 1960s.) So, yes, it was real. It is mercifully less prevalent than it was.
• gherkinnn 2y ago
  Same here. Just 10 years ago I had the displeasure of working on such a project. Months and months of upfront specification work. The UX was defined in full separately from the UI. All the DB models built in one go. Every Gantt cascade one could imagine. Horizontal slice by horizontal slice. The system was to be fully integrated at the very end, followed by a few weeks of QA. Naturally nothing worked and everything was late.
  • WillPostForFood 2y ago
    If anyone doubts that waterfall was the dominant approach to development and project management, just go back to the tools of the times, like Microsoft Project. Gantt charts were the unquestioned way you managed a project. https://upload.wikimedia.org/wikipedia/en/6/65/Screengrab_-_Microsoft_Project_9.0.2000.0224_-_%28simple_Gantt_chart%29_.png https://upload.wikimedia.org/wikipedia/en/6/65/Screengrab_-_...
    • wpietri 2y ago
      It was definitely the dominant conceptual approach, but I think it's an open question how much it was actually followed versus just being the lies everybody agreed to tell the executive caste. One way I've weaned people off waterfall approaches is just to tell them yes, of course that's what we're doing, but to make it extra safe, we'll produce software early and often so you can see progress. Then eventually I'll slip in getting users to try it, just for "testing". And then getting it deployed early, for more "testing". The smart ones get engaged in this process, using it to making things better than the initial conceptions. They may produce waterfall documents for a while, especially if they need to pacify higher ups. But often they'll just forget. I think them GANTT charts and the like were always a ritual to get them feelings of control, and they stop doing that work once they have actual control. So I suspect a lot of the nominal waterfall projects of yore were similarly made to work by developers just doing the right thing in quiet ways while saying, "Oh, that's 90% complete for sure. Mark it on your chart!"
      • hyperman1 2y ago
• pyrale 2y ago
  > it did exist. Still does, sadly.
• rtkwe 2y ago
  > with milestones where each step of the waterfall would be delivered and checked by the customer I think this is one of the things that don't explicitly follow the waterfall diagram as presented and criticized though. You're delivering smaller units of work here and I presume incorporating their feed back at least to the extent of if it is functionally meeting the specified requirements which is kind of agile-y. The main difference between the two at that point seems to come down mostly to the willingness to revisit the requirements which even when my employer was more waterfall we would try to incorporate changes if the customer came back and said what we were doing wasn't going to work at all or they needed changes.
  • theamk 2y ago
    Nope, in waterfall, "deliverables" might mean things like "UI design" (as a slide deck) or "database schemas" (on paper, without data) or "this microservice" (in isolation, and which you cannot run because dependencies and consumers are not implemented yet) If you are producing anything a customer might actually before the very end of the project, it's not waterfall.
    • rtkwe 2y ago
      That's what the article is saying in part. Very few people showed or tested absolutely nothing before the very end of the project so if that's a requirement to be 'waterfall' it was a strawman that's easy to argue against.
• rantingdemon 2y ago
  Wagile brother. It's a mix between agile and waterfall. Waterfall is great for high level governance (such as specifying high level milestones). Agile is great for executing on the deliverables. It is jus my experience. You're miles may vary.
  • randcraw 2y ago
    Of course there's a range of transitional states between waterfall and [whatever miracle cure is in vogue today]. Like all historical revisionists, today's techies like to impugn the old and laud the new. ('How could they have been so clueless?') Fact is, long-lived products, esp. from BigCorps, and esp. those in heavily regulated spaces like medicine and transportation always have and always will spend a lot more time and effort on design and process than will ephemeral products and services from startups. My software career started ca. 1990 just as waterfall was evolving into the 'Spiral' iterative software model, which since has been rebadged and remorphed several times into today's 'agile' and 'test-driven' gift from god. However in the real world, makers of every S/W product inevitably must adapt their actual development process to suit the lifecycle needs of their product and customer, in ways that scrum can't serve. Often the best way to reduce technical debt is to increase investment design and testing. And taken to NASA-like limits of fault-tolerance and reliability, that can take you all the way back to waterfall.
  • minkles 2y ago
    We use extreme waterfall. All the disadvantages of agile and waterfall in one process. Nothing gets to production due to meetings so the customers are happy we aren’t fucking anything up.
  • dehrmann 2y ago
    The whole strawman/dichotomy you see with Agile and Waterfall boils down to needing both flexibility and vision for large projects, and each fails at one of these.
  • kermatt 2y ago
    Agilefall.
  • 2y ago
• jollyllama 2y ago
  Indeed. Every real-world practice of development can be placed somewhere on the sliding-scale between Waterfall and Agile. One of the reasons that waterfall was a reasonable way to proceed was that, in the past, tighter coupling to hardware and longer hardware lead times meant the need to design and specify in advance. This is still somewhat the case where these conditions are true, albeit to a lesser degree.
• wpietri 2y ago
  Yeah, I think the Waterfall model is what naive non-experts want from a project. I say what I want, you build it, it's delivered on time and on budget, and we're done. But I think it's basically a fairy tale. "And they lived happily ever after" for executives. And I can prove it. There are basically no successful products that started with an executive idea, were created in a waterfall fashion, and then stayed at that initial version forever. Waterfall is built on the fantasy of managerial omniscience, where the people in charge know everything important on day 1. But the reality is that the beginning of a project is when we know the least. Waterfall in practice is a bet nobody will learn anything as time goes on. And on waterfall projects, that often turns out to be true, if only because course corrections would cause executives to lose face.
• dannyobrien 2y ago
  I too worked on waterfall dev projects. It was a nightmare and did not ship. The Agile Manifesto was a breath of fresh air, just because it captured what a lot of people were thinking in a way that was coherent enough to present to managers as a viable alternative.
• tgv 2y ago
  I joined a company that had adopted "agile" (in reality scrum + 2 week sprints) after a dramatic waterfall failure. They had attempted to rewrite a good, working, profitable product and had spent 2 years on the designs, only to throw it away because they just couldn't get it completed.
• eweise 2y ago
  On scrum projects I've been on, its essentially the waterfall model. Business comes up with a product and date, product and engineer give high level estimates. Program manager creates a project with all the stakeholders, product managers then write requirements, engineers then write designs. Finally this gets translated into jira epics/stories so engineers can do the implementation. The implementation runs in sprints so engineers can feel like they are doing agile. Finally when its all done, there's manual end to end testing with product and engineering.
• FartinMowler 2y ago
  Agreed! There's waterfall & agile and dogmatic & pragmatic. I've never worked on a dogmatic waterfall project but have worked on several dogmatic agile projects (that made me strongly wish I wasn't). In the pragmatic waterfall projects I worked on, during the Design phase there was still coding (by juniors, on submodules with obvious predictable designs as well as some refactoring (yes!)) and testing going on. It's just that in the Design phase it was understood any coding might need to change. In the Code/Build phase, design changes were still possible as issues were discovered (with maybe just a little more resistance). In short, we were very pragmatic about it. Much more so than with the Agile religion. The Design phase focused on designing but not exclusively so. The Build phase focused on building but not exclusively so. Humans were building things long before Agile came along. The pyramids were probably built with a pragmatic waterfall method, not an agile method (pragmatic or dogmatic).
  • ChrisMarshallNY 2y ago
    Hardware development is almost exclusively Pragmatic Waterfall. It's pretty much a requirement. Lots of reasons. Too many to list here (it would probably not be useful). As a software dev for hardware companies, most of my life, I splashed in a lot of waterfalls.
  • Tor3 2y ago
    One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the project) put extensive effort into the requirements phase. Working on the requirements and removing requirement conflicts (a very common thing), understanding of requirements, feasibility of requirements etc. etc., and, at the final stage, a week-long meeting with everyone (customer, companies) to work out the last kinks. Only after that did the next phase start: Creating software requirements from the system requirements, and from there, an architecture and so on. And, as this was something involving many companies in many countries and even continents, having everyone on the same page was essential. And it did work. Of course in the years following the project there would be bugs etc, but not fatal ones (which are typically caused by errors in the requirements- and architecture phases). (We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive) EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.
• Too 2y ago
  In those days, having in-house competence to do the coding was very rare. With each step being much more connected to a specific area of competence. Hollywoods image of programmers was that they must not be seen anywhere near a customer. This led to silos, where design was done by one group of people in the company, then sent to a third party contractor for a fixed scope and price. This naturally creates a waterfall and when everybody just sees their own silo from inside, nobody questioned the big picture, nor that their own design would be flawed from the beginning. Until the product came back, not at all working as desired. The biggest improvement today is that teams have much higher autonomy within their fully vertically integrated responsibilities. With wider areas of competence covered within a single team, or even a single person. As such, iterating and focusing on what is most important become more natural.