3 ms·

> My belief is that the waterfall approach is common not because it's effective, but because it conforms to certain naive fantasies people -- especially powerfu

> My belief is that the waterfall approach is common not because it's effective, but because it conforms to certain naive fantasies people -- especially powerful people -- have about projects. That is itself pretty naive. There is a reason why waterfall used to be popular, but it no longer is. Is it because people's ego's have ebbed? Doubtful. It's more likely that something else happened in the interim. The obvious change is the proliferation of instant communications. If communicating is hard and expensive, it often makes more sense to change things as little as possible. If it's easy, then change becomes less expensive. The internet gave us instant communication (e-mail, video conferencing, github, etc). Tools like these made agile more attractive. Humanity didn't just become enlightened.

ascar 8y ago
You are overgeneralizing one (small) enabling factor of agile as the whole reason. Maybe based on your experience in major corps. Agile doesn't start at the corp level. It starts at the individual and team level (think scrum) and maybe penetrates to the large strategic decisions on a department/corp level. Communication is cheap for teams in the same room or even people in the same building. A far greater effect is the internet itself and software/services that is/are distributed through the internet. This made shipping new versions cheap, gave an abundant access to metrics and fast feedback cycles. Cheap shipping and fast feedback enable frequent iterations. When you had to burn your software to CD and mail it to the customer releasing minor updates multiple times a week or even just every few months was not an option. You also got far less feedback and had basically no usage metrics.
- speedplane 8y ago
  You make some good points, but it still boils down to instant communication. Updating software quickly is difficult without internet. Getting feedback quickly and cheaply also isn't. So you're right that agile isn't just enabled by instant communication among developers, but I still think it's enabled by fast communication generally, including to and from the end-user.
  - AstralStorm 8y ago
    Not true at all. It is not about instant communication but about transparency and bug reporting tools. In the past, you got an app and you were lucky if the dev provided a marketing phone number for a drone to talk to. (Here is where IBM and such made bank, they did actual on site support.) Or perhaps an email address that was read manually in a year. Nowadays, a crash is automatically detected and loses some send feedback going is included in many apps for additional reports, preferably landing in a CRM directly accessed by consumers. The one problem left to tackle is marketing selling things that are not ready nor even tried out.
    - varjag 8y ago
      How is the crash reported? How do the consumers access CRM? Oh, over the Internet..
    - speedplane 8y ago
      > It is not about instant communication but about transparency and bug reporting tools. Good transparency and bug reporting tools are only possible with instant communication. If you need to call a meeting and have senior devs fly-in somewhere to report them, bug reporting is difficult, and addressing those bugs are even more difficult. If all it takes is instantly opening a github issue, you can find out about the issue and address it nearly instantly.
wpietri 8y ago
Waterfall is still quite popular, just under different names. Most of the "agile" projects I come across are really mini-waterfall. And some supposedly agile processes, like SAFe, don't even really qualify as "mini". The main difference is that some Agile labels and rituals have adopted. But there are still large deliverables whose plans are completed in advance of production beginning. Delivery is heavily or entirely weighted toward the end, with no expectation of iteration or product improvement based on early release. The major difference with the waterfall of yore is that the chunk size is not 18-36 months, but more 2-4 months. In contrast, modern Agile shops release early and often, with product choices for an initiative being informed by the real-world data generated by actual use. As an example, last I did a startup, our team of 6 was releasing a few times per day. The product manager would have an idea, find the minimum essence of it, and we would build and release that. User tests and live user data would quickly tell us whether the experiment pointed in the right direction; we'd then either double down on our bet and build a little more or we'd change direction. The average cycle time between having an idea and testing it was under a week for us. In mini-waterfall shops, that number is generally months. The reason the 18-36-month version of waterfall died out was not modern communication tools. When my dad was a developer in the 70s and 80s, you had nothing like remote work. There was a special room that the computer was in, and everybody had directly connected terminals in an office they went to every day. Some places were pure waterfall. A few were doing what we'd now call Agile, releasing new software every few days and seeing how it helped. From the way my dad tells it, the difference in the waterfall and non-waterfall shops was the extent to which executives preferred a sense of ultimate control over trusting expert staff. I agree that hasn't changed. What did change to force many companies to a shorter cycle was the change in expectations created by the rise of the internet. 18 months seemed a very long time on the web. (Although as late as 2004, I knew about one prominent brand name that did annual releases for their website.) So you'll see that consumer software now comes in smaller chunk sizes. That's sometimes true in the enterprise context and sometimes isn't. I know of 18-24-month projects at large, traditional organizations with controlling executives, captive user bases, and low-competition business environments. So waterfall hasn't gone away entirely; it may have gotten a facelift and been forced to retreat to the margins, but it's still definitely there.
- speedplane 8y ago

ascar 8y ago

You are overgeneralizing one (small) enabling factor of agile as the whole reason. Maybe based on your experience in major corps. Agile doesn't start at the corp level. It starts at the individual and team level (think scrum) and maybe penetrates to the large strategic decisions on a department/corp level. Communication is cheap for teams in the same room or even people in the same building. A far greater effect is the internet itself and software/services that is/are distributed through the internet. This made shipping new versions cheap, gave an abundant access to metrics and fast feedback cycles. Cheap shipping and fast feedback enable frequent iterations. When you had to burn your software to CD and mail it to the customer releasing minor updates multiple times a week or even just every few months was not an option. You also got far less feedback and had basically no usage metrics.

speedplane 8y ago
You make some good points, but it still boils down to instant communication. Updating software quickly is difficult without internet. Getting feedback quickly and cheaply also isn't. So you're right that agile isn't just enabled by instant communication among developers, but I still think it's enabled by fast communication generally, including to and from the end-user.
- AstralStorm 8y ago
  Not true at all. It is not about instant communication but about transparency and bug reporting tools. In the past, you got an app and you were lucky if the dev provided a marketing phone number for a drone to talk to. (Here is where IBM and such made bank, they did actual on site support.) Or perhaps an email address that was read manually in a year. Nowadays, a crash is automatically detected and loses some send feedback going is included in many apps for additional reports, preferably landing in a CRM directly accessed by consumers. The one problem left to tackle is marketing selling things that are not ready nor even tried out.
  - varjag 8y ago
    How is the crash reported? How do the consumers access CRM? Oh, over the Internet..
  - speedplane 8y ago
    > It is not about instant communication but about transparency and bug reporting tools. Good transparency and bug reporting tools are only possible with instant communication. If you need to call a meeting and have senior devs fly-in somewhere to report them, bug reporting is difficult, and addressing those bugs are even more difficult. If all it takes is instantly opening a github issue, you can find out about the issue and address it nearly instantly.

wpietri 8y ago

Waterfall is still quite popular, just under different names. Most of the "agile" projects I come across are really mini-waterfall. And some supposedly agile processes, like SAFe, don't even really qualify as "mini". The main difference is that some Agile labels and rituals have adopted. But there are still large deliverables whose plans are completed in advance of production beginning. Delivery is heavily or entirely weighted toward the end, with no expectation of iteration or product improvement based on early release. The major difference with the waterfall of yore is that the chunk size is not 18-36 months, but more 2-4 months. In contrast, modern Agile shops release early and often, with product choices for an initiative being informed by the real-world data generated by actual use. As an example, last I did a startup, our team of 6 was releasing a few times per day. The product manager would have an idea, find the minimum essence of it, and we would build and release that. User tests and live user data would quickly tell us whether the experiment pointed in the right direction; we'd then either double down on our bet and build a little more or we'd change direction. The average cycle time between having an idea and testing it was under a week for us. In mini-waterfall shops, that number is generally months. The reason the 18-36-month version of waterfall died out was not modern communication tools. When my dad was a developer in the 70s and 80s, you had nothing like remote work. There was a special room that the computer was in, and everybody had directly connected terminals in an office they went to every day. Some places were pure waterfall. A few were doing what we'd now call Agile, releasing new software every few days and seeing how it helped. From the way my dad tells it, the difference in the waterfall and non-waterfall shops was the extent to which executives preferred a sense of ultimate control over trusting expert staff. I agree that hasn't changed. What did change to force many companies to a shorter cycle was the change in expectations created by the rise of the internet. 18 months seemed a very long time on the web. (Although as late as 2004, I knew about one prominent brand name that did annual releases for their website.) So you'll see that consumer software now comes in smaller chunk sizes. That's sometimes true in the enterprise context and sometimes isn't. I know of 18-24-month projects at large, traditional organizations with controlling executives, captive user bases, and low-competition business environments. So waterfall hasn't gone away entirely; it may have gotten a facelift and been forced to retreat to the margins, but it's still definitely there.

speedplane 8y ago