Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Beyond Agile: Subsidiarity as a Team and Software Design Principle

by BrowserUk (Pope)
on Jul 22, 2015 at 02:27 UTC ( #1135770=note: print w/replies, xml ) Need Help??


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

Basically the waterfall approach is intended to apply civil engineering practices to software

That's certainly one of the problems that causes the waterfall approach to fail:

  • Mechanical engineering practices in general fail with software development because hardware deals with real, finite and deterministic units, measures and quantities.

    Software has few if any reliably measurable metrics;

  • Even the most complicated of machines -- the space shuttle for example -- has a few million parts.

    Even fairly modest software projects can have 10 or 100 times as many 'parts'.

  • Mechanical engineering projects can afford to spend big on development and testing.

    Infrastructural projects like roads, bridges, tunnels, railways, dams, houses and factories have serviceable lifetimes measured in multiple decades if not centuries; thus their development costs are amortised of those long lifespans.

    Industrial projects (turret lathes; tunneling machines; welding robots; aircon plant; windmills; aircraft etc.) amortise their costs over the production of millions of units of consumer goods or services.

    Consumer goods (cars; phones; light bulbs; printers; fridges etc) amortise their development costs over millions of units sold.

    Most software projects are one offs; and often associated with cost centers rather than profit centers. Ie. Administration rather than production.

  • The specifications for hardware can most times be definitively written down.

    If a bridge is too short...; a plane doesn't have enough fuel capacity ...; a dam can't hold back the water ....

    Software is nearly always far harder to specify.

But that is far from the only reason:

  • The single biggest problem with the waterfall methodology, is the belief by the analysts that they can construct a definitive specification up front.

    It has been proven time and time again that even the best analysts cannot fully specify anything more than the most trivial of software systems.

    And the moment you recognise that, waterfall is inevitably indicted as the root cause behind huge numbers of software projects going back 40 years or more.

  • Waterfall 'works' in the same way that erosion works: it gets there in the end.

    But unless you're writing software that will not be needed for 5 years; and will stay in service for 30 -- and almost nothing does these days -- by the time it gets there; the world has moved on. Twice if not three times.

  • Waterfall is a management heavy process from a bygone era of demigods and vassals. And it didn't even work well when that was an acceptable working practice.

    Anyone still advocating waterfall as a workable methodology in the modern world simply has no stake in anything real and current. They are living in a rose tinted vision of a misunderstood past.

  • 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.

    Your website, database, word processor, browser, compiler, PoS, phone, washing machine, even banking systems do not have either those kind of budgets nor those kind of reasons.

Better to get something working next week, find its weaknesses the week after and improve/fix them the week after that, and iterate that RAD process 6 times; than spend 6 months trying to definitively specify every last function and feature, and another 6 months getting to the point where you have something to test, only to discover your data gathering was flawed, your guesses were inaccurate, your assumptions wrong and your vision of what the customer needs is completely different from what they actually require.

But, you don't need stand up meetings or scrum masters or story boards etc. to achieve fast feedback RAD development either. Pretty much all you need is a customer's advocate with the authority to conduct regular, hands-on progress inspections; challenge decisions; and require changes.

Beyond that, there are many ways of running things -- pair working or peer reviews; tests first or mock-up and comply; continuous builds or weekly commits -- some are more appropriate to some types of software; others to others.

Strong technical leadership is good; overbearing micromanagement is bad; non-technical bean-counting counter-productive; automated bean-counting a piss-poor substitute for open and blame-free peer support and review.

Guidelines are good; blind adherence (to anything) is bad; manifestos, buzz-word compliance, cheat sheets and road-maps sops to being seen to be following 'the process'.

Waterfall has all the bads; and none of the goods. In either sense of that last word.


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: Beyond Agile: Subsidiarity as a Team and Software Design Principle

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

    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?

      ... 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!

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1135770]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2019-07-20 03:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?