in reply to Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

... software that runs the space shuttle, avionics, radiotherapy controls, etc. are all examples where waterfall *is* appropriate in my view.

I guess you missed, or didn't get as far as this bit:

There are perhaps a few dozen projects that have the funding and time and reason to be developed that way in today's world.

Aircraft & space craft control systems; nuclear power plants; medical monitoring systems; military projects. Projects with huge budgets, very long lead times and failure-is-death criteria.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
  • Comment on Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr (Friar) on Jul 22, 2015 at 03:01 UTC

    Yeah, I missed it. Thanks for clarifying. I suppose I would expand to transportation control systems generally (think the Toyota uncommanded acceleration bugs), etc. I don't htink those are just a few dozen, but entire fields of computing.

    There may be others though. And there are limits to up front design even there. Design isn't code and there are design decisions that one only gets to while coding. So it may be more of a continuum than a dichotomy.

    But surely small components help the models to converge.

    Again, we may be in agreement, just quibbling over wording.

[reply]
      (think the Toyota uncommanded acceleration bugs),

      I think its dubious to say the least that Waterfall methodology would have predicted or corrected the flaws to which that has been attributed: "Toyota did not follow best practices for real time life critical software, and that a single bit flip which can be caused by cosmic rays could cause unintended acceleration. As well, the run-time stack of the real-time operating system was not large enough and that it was possible for the stack to grow large enough to overwrite data that could cause unintended acceleration". Cross-checking, concurrent redundancy --which is what is being suggested should be required -- can be developed just as well using RAD.

      That's more a case of best-practice and legislation lagging in new fields. Drive-by-wire is new technology in road vehicles, and things haven't caught up.

      Similarly, dual-circuit brakes on cars didn't become law until circa 1976; and there were still vehicles without on the roads into the 80s.

      It's not a failure of development methodology; its failure of the specifications that didn't require cross-checked redundancy. It'll come.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]
        FWIW, the toyota issue was ruled as driver error
[reply]

In Section Meditations