Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
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!

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (5)
As of 2024-03-28 16:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found