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

With due respect that actually misses the problem.

Waterfall works when cost of failure is high (particularly when lives are at stake) and uncertainty in specification is low. There are cases where those criteria are met but those are usually not what we think of when we talk about software. The software that runs the space shuttle, avionics, radiotherapy controls, etc. are all examples where waterfall *is* appropriate in my view. If a stack overflow gives someone radiation poisoning, causes a plane to crash, or a car to accelerate out of control, this is a very different situation than "I want to track what I do for my customers."

Rather the problem is with the type of problem being solved. If you are solving a clear, precise, technical problem the considerations are different than if you are solving a business process problem which will probably be transformed in unpredictable ways by the tool you are writing to solve it.

I think we would both agree that these problems become less when components are more clearly segmented by team and by responsibility and so bounded complexity goes down?

  • Comment on Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by BrowserUk (Patriarch) on Jul 22, 2015 at 02:56 UTC
    ... 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!
[reply]

      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]

In Section Meditations