5 ms·

I understand you're joking about Agile, but the previous holy path was waterfall, which was a hideously expensive way to get to failure.

• praptak 7y ago
  Except that Waterfall was never really advocated: https://davesquared.net/2008/01/contentious-myth-of-waterfall.html https://davesquared.net/2008/01/contentious-myth-of-waterfal... It was conceived as a straw man which was being dissed so vigorously that people started believing it was real.
  • chrisseaton 7y ago
    > Except that Waterfall was never really advocated I've heard countless people advocate for waterfall. I was formally taught waterfall years ago. It was how many people approached development for a long time, and how some people still approach it today. Here's just one concrete example I could find in seconds - an article from 2006 advocating for its benefits https://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/ https://www.techrepublic.com/article/understanding-the-pros-....
    • FanaHOVA 7y ago
      Still being taught in school; my CS program in Rome had it as one of the "software engineering methods" chapters, it was part of the finals curriculum and everything.
  • JohnFen 7y ago
    > It was conceived as a straw man which was being dissed so vigorously that people started believing it was real. So much this. I've been in the industry for about 30 years, and I've never once seen a place that used a methodology that could be called "waterfall" as described by many agile proponents.
    • LanceH 7y ago
      I've been at it just as long. I've been certified in a multi-week course to work as a developer (around 2000-2002) in a waterfall system that included a VCS and some issue tracking I believe. It was always a "no true scotsman" issue. If it didn't work, it was because we didn't adhere to it and didn't gather the requirements completely enough. So, sure, waterfall never existed in the sense that it never worked out, but it certainly existed in the sense that it was pursued to the tune of countless man hours and countless dollars.
    • svachalek 7y ago
      I started out in defense and it was standard practice there, especially in regards to contract management. I had to take a formal training class in the process. It was also the only process I learned in college ('94) and was strongly advocated in my classes. Most attacks from the agile community probably are coming from a place of never having actually seen or practiced the real thing however. For example it does flow backwards at times, it's not the nonsense straight line process that gets straw-manned sometimes.
      • JohnFen 7y ago
        > Most attacks from the agile community probably are coming from a place of never having actually seen or practiced the real thing This is rather my point. In "waterfall" shops I've worked at, the way it has never worked is that the application is completely designed up front, then implemented. The reality is that there has always been iteration involved, and there has always been refining and modification of design, and etc. The only thing (aside from "ceremonies") I see agile bringing that didn't exist in my experiences with "waterfall" is the notion of bringing the customer in as a constant part of the development process -- which is a welcome addition. The rest of Agile that I see can be thought of as refinements to waterfall, not as something entirely different.
    • logfromblammo 7y ago
      I worked in a place that called it "spiral". Because they did the phases of waterfall over and over again, until finally drilling down through the roof of Hell. Yes, it was horrible. Yes, it got worse when they added the mandatory omnibus all-hands standup scheduled for 8:45-9:00 every morning, that always somehow lasted until at least 9:30, because everyone was continually justifying their existence. And it was redundant with the spreadsheets that recorded the time spent on any particular task, down to the second.
  • projektfu 7y ago
    Waterfall represents the default approach to managing chaos. One or two programmers with a single customer have an easy time getting a job done. When the budget gets into the millions, the project fails from having too many chefs in the kitchen, etc. So the gut reaction is to overload the front end with process. Finish requirements first, create a high level design, split it up into components that can be implemented, create a detailed design for each component, implement the design, integrate, test. I heard a ton of times as a consultant from average people, "we needed to specify more of this up front and create better designs ahead of implementation." It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. You don't have to follow an agile methodology to acheive a successful project, but you do have to have feedback loops that reduce the risk of wasted effort. In the engineering analogy, I like to tell people that the compiler is the builder. All coding is an exercise in architecture and engineering that produces a detailed design (the code).
    • LordFast 7y ago
      > It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. In my experience very few people truly understands why engineering is something expensive at its core, and it's usually this particular lack of understanding that ironically ends up making making things even more expensive and produces worse value-for-money, and so the vicious cycle continues.
    • jandrese 7y ago
      I've seen too many projects where the specification guys were basically writing the whole program suite in English and then expecting it to just translate smoothly to computer code. Then their beautiful 5 year late 2000 page specification slams head first into the realities of computers and the project immediately becomes quagmired. It's basically the Soviet model of computer programming, where you try to make all of the design decisions from the top but the people at the top don't have the whole picture and can't make good decisions and the scope is way too large for mere mortals to learn enough to make said decisions.
  • aaronharnly 7y ago
    I thought that was true, but I had a vendor just last week state out loud, “We use a waterfall methodology.” It is alive and well, even if the smartest thinkers in the field never subscribed to it literally.
  • convolvatron 7y ago
    thank you. I try not to post just to vehemently agree, but this is a pretty egregious case of revisionism. we were just so blind back then that we thought we could predict the future. When faced with direct evidence that things weren't going according to plan, or that the commercial landscape had changed, we stubbornly went back to our Gantt charts and insisted that it just couldn't be so. so we just never got anything done..until some genius decided we had to meet every morning and schedule everything in 2 week intervals.
  • cc81 7y ago
    It was advocated, it was not meant to be advocated, but it was. And Agile has it's fault and it has become filled with consultants, buzzwords and all kinds of things but early days when I built an internal system used in factories for a large company. The old ways of building and documenting software there was pretty much waterfall and there was a lot of middle-management, reporting, architects, documenting etc. I was a part of a pretty young team + one offshore team in India (that was not great but not bad either) and we had a great boss who fought for us when we wanted to develop using pretty standard Scrum instead and we had a great product owner who immediately got what we were after and had great domain knowledge. That project went sooo much better than previous ones and even if there were a lot of fighting and escalations in the beginning the whole concept of "Just call into our demo's we have every three weeks and see what we are developing and then give feedback" was like a revelation for some would be users of the system or owners of processes we implemented.
  • jdmg94 7y ago
    waterfall wasn't advocated because there hadn't been a movement for alternatives yet, it was just the default, like the iphone 2G, nobody called it iphone 2g when it came out, but in the context of newer models that's how we differentiate it
  • Izkata 7y ago
    Waterfall on a per-feature basis is how we did things about a decade ago. It may be rare, but it's not a strawman.
  • goto11 7y ago
    Oh yes it was advocated. Maybe the actual term "waterfall" was invented in order to criticize the methodology, but it was describing and criticizing a real, commonly used methodology. Waterfall is really how you manage other large construction projects like building a house or a bridge. So it is not completely crazy to think you can also develop software that way. It took many failures to realize software demanded a different approach.
• dmitriid 7y ago
  Most of what we call agile today is processes for the sake of processes and waterfalls in disguise.
  • xtracto 7y ago
    Yes! I remember when I was in University (1990s) how they taught us about how waterfall was bad and iterative development processes were just starting (XP was still not invented). Iterative development processes where beautiful, and had great ideas. The problem with today's "Agile" methods as implemented in the industry is that they usually only do the first iteration and stop there, making it practically mainly waterfall.
• GuB-42 7y ago
  The problem is neither agile nor waterfall. The problem is applying a methodology because it is the current fad. Management should be adapted to the conditions: the scale of the project, the nature and availability of the customer, the personalities and roles of the team members,... Sometimes, the best results looks like waterfall, sometimes it looks like agile, sometimes it looks like there is no methodology at all. When things "just work" you don't realize there is a process, that's the sign of a manager doing a good job. The worst case is usually when a manager follows a methodology "by the book", except for the parts that don't fit or are "too expensive". Not realizing that pieces go together and changing one will affect the others. The same could be said of design patterns in programming. They are good to know, but they are just guidelines. Using a design pattern for the sake of it usually leads to terrible, often bloated code.