tl; dr: I think Waterfall vs. Agile religious war is wrong; it's mostly about that you can't hit a moving target without a feedback loop.
That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile).
Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.
Agreed. Waterfall is usually better when you do client projects. Agile would be better when you do your own product, at the same time Agile may lead to cost overrun.
arctangent|14 years ago
But they're probably running a computer model of the jet (and its systems) under various simulated scenarios.
They're also probably building some full-scale mock-ups to test in wind tunnels.
And they also have test pilots to fly things which sometimes never make it into wide scale production.
So, I'd argue that there is some iteration going on there.
martininmelb|14 years ago
pnathan|14 years ago
In the 1950s, test pilots were being killed at the rate of about one a week[1]
[1]http://en.wikipedia.org/wiki/Test_pilot
TeMPOraL|14 years ago
That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile).
Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.
aidenn0|14 years ago
johnx123-up|14 years ago
dylancm|14 years ago