4 ms·

Did Agile definitely kill Waterfall?

9 points by sandrobfc 8y ago

mimixco 8y ago
Big companies with lots to lose will always use a waterfall process. Facebook can move fast and break things because there's little risk to them, but fintech, legal, military, and medical software will always require peer review and a waterfall process. When I was a mainframe programmer at IBM, it was the waterfall process that protected customers from untested code and, as a result, you don't hear much about giant hacks or thefts in things like bank accounts, Social Security checks, or industrial manufacturing. That's because the suppliers of those programs don't want to move fast and break things. They want to move slowly and be sure that software works, to the best of their ability, before shipping.
- sandrobfc 8y ago
  I don't think that Agile is always about being more risky. Sure, Waterfall is a safe way to go in most projects, but what about the possible losses in costs and effort that may come from it? However, I do get your point regarding safety for the client itself, that don't want to risk shipping an "unfinished" product.
  - mimixco 8y ago
    It is inherently risky in that it encourages shipping first and fixing stuff later. This is the opposite of what you do with something like someone's bank account. (Yes, ETH Solidity developers, I'm talking to you.) I absolutely love the agile process and I'm a big believer in pair programming, which was part of the original doctrine but is hardly mentioned today. That being said, no one is smart as all of us and there are inevitably things in your code which you (two) as developers won't immediately discern. Waterfall, though protracted and boring, is crucial for identifying and fixing those problems before they ship.
gregjor 8y ago
No. In fact a lot of waterfall projects just get called agile.
- sandrobfc 8y ago
  A lot of processes, overall, are called Agile just for the sake of marketing. But concerning the way in which they operate, would you say that Waterfall is still the most used method nowadays (just masked as Agile most of the times)?
  - gregjor 8y ago
    I would say ad hoc has always been the dominant software development method, and still is. Whether we call it waterfall or agile depends on external trappings of project organization and depth of requirements. But once underway development proceeds the same way: stumbling from one set of vague requirements and moving deadlines to another. Few organizations have the discipline to define complete and unambiguous requirements in advance, or to predict development times with any accuracy (waterfall). Likewise few organizations have the discipline to discover requirements and build in the agile feedback loops. In the end it comes down to either slogging along or luck, and it’s always been like that. A few teams somehow come together and produce working products that succeed. Most teams don’t. What you call the method doesn’t matter much, because team and interpersonal dynamics drive development success and failure far more than technical skills and tools or management structure and planning.

9 points by sandrobfc 8y ago

Big companies with lots to lose will always use a waterfall process. Facebook can move fast and break things because there's little risk to them, but fintech, legal, military, and medical software will always require peer review and a waterfall process. When I was a mainframe programmer at IBM, it was the waterfall process that protected customers from untested code and, as a result, you don't hear much about giant hacks or thefts in things like bank accounts, Social Security checks, or industrial manufacturing. That's because the suppliers of those programs don't want to move fast and break things. They want to move slowly and be sure that software works, to the best of their ability, before shipping.

sandrobfc 8y ago
I don't think that Agile is always about being more risky. Sure, Waterfall is a safe way to go in most projects, but what about the possible losses in costs and effort that may come from it? However, I do get your point regarding safety for the client itself, that don't want to risk shipping an "unfinished" product.
- mimixco 8y ago
  It is inherently risky in that it encourages shipping first and fixing stuff later. This is the opposite of what you do with something like someone's bank account. (Yes, ETH Solidity developers, I'm talking to you.) I absolutely love the agile process and I'm a big believer in pair programming, which was part of the original doctrine but is hardly mentioned today. That being said, no one is smart as all of us and there are inevitably things in your code which you (two) as developers won't immediately discern. Waterfall, though protracted and boring, is crucial for identifying and fixing those problems before they ship.

gregjor 8y ago

No. In fact a lot of waterfall projects just get called agile.

sandrobfc 8y ago
A lot of processes, overall, are called Agile just for the sake of marketing. But concerning the way in which they operate, would you say that Waterfall is still the most used method nowadays (just masked as Agile most of the times)?
- gregjor 8y ago
  I would say ad hoc has always been the dominant software development method, and still is. Whether we call it waterfall or agile depends on external trappings of project organization and depth of requirements. But once underway development proceeds the same way: stumbling from one set of vague requirements and moving deadlines to another. Few organizations have the discipline to define complete and unambiguous requirements in advance, or to predict development times with any accuracy (waterfall). Likewise few organizations have the discipline to discover requirements and build in the agile feedback loops. In the end it comes down to either slogging along or luck, and it’s always been like that. A few teams somehow come together and produce working products that succeed. Most teams don’t. What you call the method doesn’t matter much, because team and interpersonal dynamics drive development success and failure far more than technical skills and tools or management structure and planning.