[HN Gopher] The Waterfall Model was a straw man argument from th...
___________________________________________________________________
The Waterfall Model was a straw man argument from the beginning
(2015)
Author : ern
Score : 141 points
Date : 2024-09-15 07:12 UTC (1 days ago)
(HTM) web link (www.jjinux.com)
(TXT) w3m dump (www.jjinux.com)
| ggm wrote:
| Waterfall might have been a straw man but SADT and other
| structured design principles put an unbelievable amount of
| dependency on diagrammatic and black box formalised boundaries of
| flow. All done up front.
|
| People mocked things and prototyped things but I sat beside
| people who worked for 2 years or more on wall sized collections
| of ring binders of requirements specifications and flow charts,
| to end in acrimonious lawsuits.
|
| I do kind of hate agile language. It's smug. But I love rapid
| prototypes and sprints.
| anonzzzies wrote:
| In my field (troubleshooting for enterprises), I encounter,
| literally every day, prototypes (rapidly thrown together things
| that 'work-ish') in production and spewing bugs. I wonder where
| these companies are that actually toss the prototype and do it
| proper afterwards. Never seen it live, only on paper.
| piva00 wrote:
| I've done many, many Proofs of Concept that were thrown out
| after exploration to make way for properly written production
| code. It's part of any new greenfield project I work at, we
| do a rapid prototype to validate some early design, learn
| from it and throw it out.
|
| My field is not enterprises though, I worked all of my 20+
| years career at tech companies of different sizes (from
| startups to 10k+ people orgs), startups and smaller companies
| usually will throw a PoC into production, and call it "tech
| debt" for later, larger orgs tend to avoid that since they've
| been previously burnt by the maintenance burden of poorly
| designed code in production (usually on their startup-ish
| phase).
| bryanlarsen wrote:
| OTOH, I've been in that situation too, and it was successful.
| The International Space Station has not yet fallen out of the
| sky. There are situations where waterfall is appropriate.
| harshitaneja wrote:
| I am curious if this is usually argued. I thought it that was
| generally held that agile and similar methodologies at least
| in the sense that sprints are defined in days/weeks and not
| months/years is for use cases where the product doesn't have
| well defined specifications.
| mathw wrote:
| And yet the ISS has still had many bits added on, replaced,
| upgraded and modified. They just work to far, far higher
| standards than almost any company will pay for because they
| know if it goes wrong some very high profile people get dead.
| turtleyacht wrote:
| Link to Dr. Royce's paper, _Managing the Development of Large
| Software Systems_ (1970):
|
| https://www.praxisframework.org/files/royce1970.pdf
| Tor3 wrote:
| "Every time I read about the Waterfall Model, I think to myself:
| I'm sure there must be companies out there that have tried this
| approach, but I have a hard time believing some software book
| would seriously propose it as the best way to write software"
|
| I've been on software development projects (the final product
| would be source delivered to the customer) where the waterfall
| model was explicitly specified, with the whole design- and
| implementation phase based on this, with milestones where each
| step of the waterfall would be delivered and checked by the
| customer. This was particularly prevalent back in the eighties
| and beginning of the nineties. It's as real as can be, it did
| exist. Obviously developers couldn't follow that 100%, so there
| would be some amount of back-designing an earlier stage, but if
| it wasn't 100% it was very close in practice too.
| 2OEH8eoCRo0 wrote:
| Having worked waterfall and now agile, I miss waterfall. Agile
| feels too fast and loose. We work faster but we also redo a lot
| of things. It's an illusion of progress.
| datavirtue wrote:
| What you describe is from micro-managent of the development
| process. I have never met anyone qualified to micro-manage a
| software project, and never will.
| abakker wrote:
| it works the same if you apply it to other disciplines. The
| saying, "a plan is useless, but planning is invaluable".
| Agile just skips the second part by trying to throw out the
| first part.
|
| I think a real criticism of Agile would be that it works
| great assuming a) domain expertise and b) good understanding
| of how accurate / precise a solution has to be to work.
|
| Agile seems to work best when the domain itself is
| technology, rather than, say, when the domain is HVAC control
| or real-time ECMs.
| j-a-a-p wrote:
| Oh, I always think the opposite. If the outcome is
| technical, then quit playing, RTF specs, design and build
| it. If the outcome is some wobbly user expectation, wobble
| back with Agile.
| abakker wrote:
| there's probably a rational category based on the
| size/complexity of the data model. I get the sense that
| very complicated data models are what really ruins the
| agile approach for complex environments.
| morkalork wrote:
| How much do you think it was an artifact of the time? Agile
| relies on it being fast/cheap/easy to ship and deploy
| incremental changes. I have a hard time believing that to be
| the case in the 80s. When planning and designing on paper is
| cheap in comparison, it makes sense to me that is the
| development method people used.
| makeitdouble wrote:
| I think it was more about the corporate culture which
| dictated that people had a plan and stick to it.
|
| It's still the case in many trades. You don't build a house
| or a bridge the Agile way for instance.
|
| IMHO Agile got a lot more prevalent because the planning
| phase became more and more onerous to have any reliability,
| and management was tired of paying upfront for it. I steady
| they could get a more regular billing (in particular when
| dealing with consulting companies) with reports of stuff
| allegedly shipped, instead of six months of "we're planning
| very hard, just trust us". Whether the end result matched
| what they needed/wanted to build being another story.
|
| I know many companies that had an official Waterfall cycle,
| while actually working on something more granularly shipped
| with many phases of prototyping. And they didn't move to
| Agile either, just stopped calling their process anything and
| went on doing whatever felt right.
| benfortuna wrote:
| >It's still the case in many trades. You don't build a
| house or a bridge the Agile way for instance.
|
| Looking at how some houses are built these days, a case
| could be made for Agile over "do your best, silicone the
| rest".
| detourdog wrote:
| I find agile passive aggressive because the consensus is
| built under duress. I prefer a well reasoned approach. I can
| understand agile process in between waterfall milestones.
|
| I can even support an agile process to create waterfall
| process.
| datavirtue wrote:
| Developers are still constrained by process, and it's their
| fault.
|
| In every single company I have worked, the process always
| took priority. It's made even worse where you have ISO 9001
| compliance where every god damn thing in the company is
| locked into a "process." Process over people, period.
| Coporo-managers can't get it out of their head.
|
| When all you have ever done is "the process" it looks
| perfectly sane. To teams that can produce a POC and
| basically get to market on their own domain knowledge, it
| looks ridiculous. Making developers wait for requirements
| instead of inventing them on the fly is incredibly slow and
| smothers nearly all innovation.
|
| Why risk making your product look like your convoluted
| communication and political structures? The entire point of
| agile was lost on the influx of bodies to the industry.
|
| Form a "skunk works" team and shield them. Make a big show
| of how their success came despite having zero fucking
| process. Jira is for maintenance.
| kayodelycaon wrote:
| > Developers are still constrained by process, and it's
| their fault.
|
| How is it my fault? I don't get to make the decisions and
| I can't just change jobs if management doesn't listen.
| toast0 wrote:
| > In every single company I have worked, the process
| always took priority.
|
| If process (or freedom from process) is important to you,
| you need to make it a priority when you're interviewing.
| May depend on what industry you work in, of course, some
| industries don't have any cowboys.
|
| That said, I like my cowboy jobs with a little bit of
| process. What's deployed in production should be
| reflected in source control, but I'm not a stickler for
| which comes first. A change notification should be posted
| before production is changed, but if you have separate
| push and load steps, you can push before you notify (if
| pushing takes a while, it's good pipelining to use the
| push time to compose your change notice). Changelogs
| usually shouldn't be 'bugfixes' or 'latest', but 'fixing'
| is appropriate for a close in time followup. That's
| process, even if an ISO compliance officer would lose
| their mind.
| Tor3 wrote:
| At that time the waterfall model method was one solution to
| the problem of software quality. Other methods hadn't yet
| been developed (or at least not become well known yet), and
| waterfall was in use by the industry (not everywhere though -
| re sibling comment). The customer I mentioned was _huge_ and
| lots of companies in lots of European countries, and overseas
| too had development contracts which demanded this process to
| be used. And the results were actually good, even though the
| process was heavy. That didn 't mean that it couldn't be
| improved on, and that did happen later, with more agile-like
| (though not "Agile") methods modifying the approach.
| KineticLensman wrote:
| > How much do you think it was an artifact of the time?
|
| I was a software engineer in the 90s at a small company (15
| people) doing simulation development for the UK Ministry of
| Defence. We had two distinct software development processes,
| which were waterfall and a form of rapid development known as
| the Dynamic Software Development Method (DSDM). (I threw away
| the manuals years ago so can't give more info).
|
| The company directors came from an aerospace background so
| had a very strong software quality focus. Many of our
| contracts specified waterfall and our project artefacts
| reflected that - user requirements docs, system requirements,
| architectural design, detailed design, integration test
| plans, system tests, acceptance tests, etc etc. Coding
| happened somewhere in the middle. It did work, sort of, in
| situations where the customers knew what they wanted, and we
| mutually understood it. Which was quite often the case, for
| our regular customers on projects that were extending
| existing systems.
|
| We trialled DSDM for projects where the customer said
| 'prototype' and I liked it. It lacked the onerous agile /
| scrum boilerplate and IIRC was based around loosely specified
| timeboxes and relied on having 'intelligent customers' who
| were prepared to be flexible in terms of what they got at the
| end.
|
| The need for DSDM was motivated by a project that failed
| badly (not with the MOD) because the customers said 'here are
| our requirements for this prototype system, don't come back
| until you have finished and tested it'. Needless to say the
| result wasn't what they expected, even though all of the
| requirements had been, on paper, met.
|
| But for any development where specific technical outcomes
| were necessary (e.g. a maths module), waterfall would usually
| be used.
| j-a-a-p wrote:
| I got a course at Oracle on DSDM RAD (rapid application
| development) and worked on a project with it. The 4GL
| tooling used at Oracle were no good fit, but back then also
| Oracle was moving up to 3GL tools like JDeveloper. And they
| thought using RAD was good fit.
|
| Key what I remember was time boxing. And much less
| religious stance than Agile. But back then it was normal to
| have different people doing functional designs, technical
| designs, database design (also in two levels) and business
| process design of sorts. I guess it took a while for these
| people to realise they had to be Agile digital
| transformers.
|
| And I guess it also did not help the DSDM also certified
| people on the waterfall methodology.
| SoftTalker wrote:
| I think it was an artifact of applying physical construction
| project concepts to building software.
|
| If you're building a house, or something bigger, you don't
| just start nailing lumber together. You have a blueprint.
| Pretty detailed, and it uses industry-standard terms and
| markup. Any builder can take it and use it to construct the
| building. It has the dimensions and specifications for the
| foundation and all the rooms. It has considered where the
| rooms are, which walls are load bearing, where the staircases
| and HVAC and plumbing and electrical runs are, where the
| windows and doors are, pretty much everything. An engineer
| has signed off on the overall design as being safe and
| meeting all the applicable codes. You can order a list of
| supplies based on this plan and you'll be within a few
| percent of what you actually use.
|
| Some small changes were allowed. You could change finish
| details like what style of cabinets or trim or door knobs
| would be used. But you could not really approach the builder
| once the framing was complete and say actually I wanted the
| living room over _there_ and the bedrooms over _here_ and
| also I want to add a third storey. You also didn 't build one
| bedroom, and then based on that experience extrapolate the
| design for the next one, and then apply that to building the
| kitchen, and so on. It was all done up front.
|
| People, especially people who were used to managing physical
| projects, thought that with the same level of planning, and
| the same approach to management, the same results could be
| achieved in software projects.
| JohnFen wrote:
| > I've been on software development projects (the final product
| would be source delivered to the customer) where the waterfall
| model was explicitly specified
|
| On the other hand, in my 50 years or so in this business,
| working with every size of company, I have never actually seen
| "waterfall" being done in practice. I'm sure it may have
| happened -- as you report -- but I don't think it was ever
| common.
| convolvatron wrote:
| I have certainly seen projects that started by planning
| everything out. High level designs, milestones, integration
| dates. Giant GANNT charts. But by the second quarter everyone
| was pretty much just redrawing the whole map, getting what
| they could running as early as possible and throwing things
| off the bus.
| Supermancho wrote:
| I still see it today, in various projects.
| jerf wrote:
| If you consider this not as a binary choice, but "waterfall"
| on one end meaning that the whole design process has
| basically no feedback, and "agile manifesto agile" (not scrum
| or any other calcification of the process, but the true
| chaotic "just depend on your engineers to be smart" process),
| it's probably true there has never been a "true", all-the-
| way-to-one-end Waterfall design that went for multiple years,
| because such a thing is essentially impossible.
|
| It is absolutely the case though that many projects were
| driven with management methodologies _way, way_ too far to
| the Waterfall side, and that managers would attack developers
| for essentially failing the process if anybody ever had to
| incorporate feedback or backtrack or do anything other than
| 100% rigidly and correctly follow the previous plan.
|
| I don't consider it a "strawman" so much as a
| "simplification". Nobody could ever truly do waterfall for
| extended periods of time but there were plenty of people who
| acted and managed on the idea that the ideal is very, very
| close to it and to the extent deviations were necessary they
| are all automatically failures. To the extent that one is
| trying to discuss management methodologies across an entire
| industry, if not arguably across multiple industries
| simultaneously, waterfall is not an unreasonable
| approximation.
|
| And personally I think in the occasional interminable "oh
| wouldn't it be _wonderful_ if programmers were _real
| engineers_ like _architects_ " threads, where people fail to
| understand those processes used by other engineering
| disciplines are contingent based on the nature of their work
| rather than abstract Platonic ideals all should strive for,
| and those other disciplines would _love_ to work with
| continuous integration servers and automated testing and
| strongly-typed components, there are a lot of developers that
| believe even today that if we _just tried hard enough_ ,
| waterfall could not only work but be the optimal design
| methodology, and it is we who are failing waterfall rather
| than the other way around.
| whatnotests2 wrote:
| > And personally I think in the occasional interminable "oh
| wouldn't it be wonderful if programmers were real engineers
| like architects" threads, where people fail to understand
| those processes used by other engineering disciplines are
| contingent based on the nature of their work rather than
| abstract Platonic ideals all should strive for, and those
| other disciplines would love to work with continuous
| integration servers and automated testing and strongly-
| typed components, there are a lot of developers that
| believe even today that if we just tried hard enough,
| waterfall could not only work but be the optimal design
| methodology, and it is we who are failing waterfall rather
| than the other way around.
|
| You captured so much in this one sentence, especially the
| end, about how waterfall failed the developer, rather than
| the developer having failed waterfall.
|
| This script-flip works on many other systematized
| orthodoxies, I suspect.
| JohnFen wrote:
| > I don't consider it a "strawman" so much as a
| "simplification"
|
| I consider it a straw man because, as the agile crowd
| describes it, there appears to be no such thing as
| "waterfall". Perhaps that is the result of comical
| oversimplification rather than a conscious attempt at
| deception (I believe this is the case), but it still
| results in standing up a straw man so it can be knocked
| down.
| jerf wrote:
| If a process is 98% waterfall and management blames
| developers for the 2% and considers it a problem to be
| solved rather than something to be harnessed, it's close
| enough to waterfall for all practical purposes. I don't
| believe there's a sudden transition in the cost/benefits
| for waterfall at 100%, in either direction. (Just as I
| don't believe it for Scrum.) The criticisms will apply.
| JohnFen wrote:
| > If a process is 98% waterfall
|
| I just haven't seen that happen. I'm sure there are
| exceptions where it has, but I think those have always
| been rare.
| thwarted wrote:
| _And personally I think in the occasional interminable "oh
| wouldn't it be wonderful if programmers were real engineers
| like architects" threads, where people fail to understand
| those processes used by other engineering disciplines_
|
| If the software industry had the equivalent of "general
| contractors" who pour the concrete, wire the rebar, dig and
| fill the holes, install the electrical and duct, laid the
| bricks, all to within the tolerances specified; AND had
| architects who knew both the tools available and the domain
| inside and out, a model mirroring the real estate industry
| MIGHT BE doable. But there are a lot of differences beyond
| just the "engineering" aspects (and often times, the head
| engineer on a project is not the architect).
| randomdata wrote:
| It's not really binary or a spectrum. Royce was not taking
| about what he observed people doing, but how he believed
| large software projects should be conducted in the future.
|
| In that, he first introduces what has come to be known as
| Waterfall. While he considered it to be fundamentally
| sound, he posits that it carries significant risk and then
| goes on to tell what needs to be added to diminish the
| risk. Those additions are what oft get called Agile
| (although not in the Manifesto sense).
|
| You have a point that "simplification" is more in line with
| the device he was trying to use, but with the intent of
| leading you into understanding the more complex aspects of
| his idea. Kind of like that owl drawing meme where you
| start with two circles and then draw the rest of the owl.
| There is only one idea present. In other words, "Waterfall"
| and "Agile" are the _exact same thing_ , just at different
| stages of communication.
|
| Where others have tried to invent "Waterfall" as it own
| distinct thing to contrast with "Agile", it would be fair
| to characterize that as a strawman. If anything all
| projects are "Agile" at their core, with varying degrees of
| deviation happening in a multi-dimensional space.
| Swizec wrote:
| > On the other hand, in my 50 years or so in this business,
| working with every size of company, I have never actually
| seen "waterfall" being done in practice. I'm sure it may have
| happened -- as you report -- but I don't think it was ever
| common
|
| In my ~20 years of mostly startups and small businesses I
| have seen waterfall creep in at almost every company. You
| start by being small-a agile because there is no process.
| Then something happens - a few big fires ship, or someone
| misses a requirement, or an exec gets grumpy about feeling a
| loss of control, or internal users start treating it as just-
| a-job and want official training for every little thing, or
| you get engineers who just want to code - and your small-a
| agile process turns into waterfall.
|
| Ah but we're a startup, we can't do waterfall! So you do a
| series of tiny waterfalls and call them Agile. Everything
| takes eons of planning, the management class feels super
| busy, the engineers become disempowered and widget factory
| like, and all the plans are wrong by the time you implement.
|
| You start getting lots of "we'll figure out the details then
| engineers just need to implement, it'll be easier that way".
| It is not easier that way.
| whatnotests2 wrote:
| Ah yes, the Agile Waterfall method. Lol
| convolvatron wrote:
| This entire discussion or dichotomy is just a massive and
| sad misdirection. Its explicitly cargo-culting. In what
| other world do we spend half of our time talking about and
| conforming to various 'methodologies'. If we just find the
| right sprint cadence. If we just do retros better. Maybe
| some kanban-scrum hybrid. If we just _reallly_ limit
| standups to 15 minutes. If we clap three times at the end
| instead of two - then perhaps we will be able to deliver
| software.
|
| There has to be some process, for tracking and
| communication. We should just have an industry-wide
| standard that management gets to impose a 5% process tax on
| hours spent and no more. And we should explicitly recognize
| that test, design, communication, teaching, engaging with
| the customer, triage and debugging are how software gets
| built. There is no magic process bullet. Its a wasteful
| story invented by management who existentially cannot admit
| that they have no control over the situation.
| Swizec wrote:
| > In what other world do we spend half of our time
| talking about and conforming to various 'methodologies
|
| Remember that this is largely about consultants selling
| advice to executives. This is not about getting stuff
| done.
|
| BUT software is also a young industry. We just don't know
| yet the right way to do it so we discuss and share what's
| worked for us. Just like it took a while to find the
| right manufacturing processes in other industries.
| HeyLaughingBoy wrote:
| That's because the "right way" needs to vary depending on
| what you're building. You don't build a garden shed the
| same way you build a skyscraper. Likewise, you don't
| build a twitter client the same way you build an
| implantable pacemaker.
| cruffle_duffle wrote:
| And for that matter you don't build a twitter client the
| same way you built a backend for twitter clients to
| connect to. In my experience every team and project has a
| unique way of working and that could be encouraged.
| HeyLaughingBoy wrote:
| Neither have I. Most of my software career has been spent in
| medical device development: a tightly regulated industry, and
| waterfall is just a concept.
|
| Sure, you do requirements elicitation, review and
| documentation, and then architectural design, followed by
| detailed design & coding, etc. But it's never a linear
| process end-to-end. There's always feedback. There's always
| something you didn't account for showing up and requiring a
| change to an earlier part of the process.
|
| Waterfall can, and does work, but only on fairly small
| projects that can be completely defined correctly the first
| time around. And like everything else, it's easier if you've
| done that kind of project before.
| torginus wrote:
| Honestly I could see it working in projects with inherently
| high complexity and/or set timelines like operating systems,
| compilers, video games.
|
| There's often a clear goal in these cases, and there's no
| 'minimum valuable product' you can quickly iterate on.
| benfortuna wrote:
| The requirements and design phases can/did often work very
| well. It's what comes after that derails the process.
|
| When you spend more time trying to update your design to
| match the implementation (via change requests) than
| implementing you start to wonder if there's maybe a better
| way..
| AnimalMuppet wrote:
| I think waterfall and waterfall-ish development is more
| prevalent in government contracting. You aren't building for
| yourself, you're building for a single external customer, and
| you have to build both the functionality and the interfaces
| that they want.
|
| And I note that government contracting was probably a bigger
| fraction of all software engineering in the 1980s than it is
| today. (Still more in the 1960s.)
|
| So, yes, it was real. It is mercifully less prevalent than it
| was.
| gherkinnn wrote:
| Same here. Just 10 years ago I had the displeasure of working
| on such a project. Months and months of upfront specification
| work. The UX was defined in full separately from the UI. All
| the DB models built in one go. Every Gantt cascade one could
| imagine. Horizontal slice by horizontal slice. The system was
| to be fully integrated at the very end, followed by a few weeks
| of QA.
|
| Naturally nothing worked and everything was late.
| WillPostForFood wrote:
| If anyone doubts that waterfall was the dominant approach to
| development and project management, just go back to the tools
| of the times, like Microsoft Project. Gantt charts were the
| unquestioned way you managed a project.
|
| https://upload.wikimedia.org/wikipedia/en/6/65/Screengrab_-_.
| ..
| wpietri wrote:
| It was definitely the dominant conceptual approach, but I
| think it's an open question how much it was actually
| followed versus just being the lies everybody agreed to
| tell the executive caste.
|
| One way I've weaned people off waterfall approaches is just
| to tell them yes, of course that's what we're doing, but to
| make it extra safe, we'll produce software early and often
| so you can see progress. Then eventually I'll slip in
| getting users to try it, just for "testing". And then
| getting it deployed early, for more "testing". The smart
| ones get engaged in this process, using it to making things
| better than the initial conceptions. They may produce
| waterfall documents for a while, especially if they need to
| pacify higher ups. But often they'll just forget. I think
| them GANTT charts and the like were always a ritual to get
| them feelings of control, and they stop doing that work
| once they have actual control.
|
| So I suspect a lot of the nominal waterfall projects of
| yore were similarly made to work by developers just doing
| the right thing in quiet ways while saying, "Oh, that's 90%
| complete for sure. Mark it on your chart!"
| hyperman1 wrote:
| Something similar happened to flow charts. They get
| unreadable after a few tens of LOC, but the managers
| required them. So people dutifully shipped tons of paper
| upstairs, and nobody ever read them. Then they were drawn
| after the source was written, instead of before. Then a
| computer program generated them straight from the source
| code. Then they stopped printing them, storing them on
| disk instead. Then the flow chart generator broke, and
| nobody noticed the write-only documentation was missing.
| Finally, some manager got the genius idea to speed up the
| process by not requiring flow charts anymore.
| imbnwa wrote:
| >It was definitely the dominant conceptual approach, but
| I think it's an open question how much it was actually
| followed versus just being the lies everybody agreed to
| tell the executive caste.
|
| Its funny because that would the inverse of the current
| situation where exec proclaims their company is agile to
| external observers and potential hires, but the de facto
| regime could be anything
| sumtechguy wrote:
| One company I worked with we switch over from waterfall to
| agile. The 'guardian' of the rooms of paperwork was so
| happy when she could bin 2 rooms full of filing cabinets
| overflowing with designs no one really followed. Took her
| about a week to clear it all out. Hundreds of rolls of
| gantt charts dumped into a recycle dumpster. Basically we
| stopped pretending we were not redesigning everything as we
| went along.
| hadlock wrote:
| > If anyone doubts that waterfall was the dominant approach
| to development and project management
|
| I've never felt so old in my life
| ang_cire wrote:
| Haha, yeah, hearing things you literally did being
| discussed like they're urban legends. xD
| afpx wrote:
| I worked professionally from the late 90s. We used Gantt,
| but it was always for spiral or unified process. We were
| always told to avoid waterfall (as there's a natural
| tendency to go that way) and always include feedback loops.
| pyrale wrote:
| > it did exist.
|
| Still does, sadly.
| rtkwe wrote:
| > with milestones where each step of the waterfall would be
| delivered and checked by the customer
|
| I think this is one of the things that don't explicitly follow
| the waterfall diagram as presented and criticized though.
| You're delivering smaller units of work here and I presume
| incorporating their feed back at least to the extent of if it
| is functionally meeting the specified requirements which is
| kind of agile-y.
|
| The main difference between the two at that point seems to come
| down mostly to the willingness to revisit the requirements
| which even when my employer was more waterfall we would try to
| incorporate changes if the customer came back and said what we
| were doing wasn't going to work at all or they needed changes.
| theamk wrote:
| Nope, in waterfall, "deliverables" might mean things like "UI
| design" (as a slide deck) or "database schemas" (on paper,
| without data) or "this microservice" (in isolation, and which
| you cannot run because dependencies and consumers are not
| implemented yet)
|
| If you are producing anything a customer might actually
| before the very end of the project, it's not waterfall.
| rtkwe wrote:
| That's what the article is saying in part. Very few people
| showed or tested absolutely nothing before the very end of
| the project so if that's a requirement to be 'waterfall' it
| was a strawman that's easy to argue against.
| rantingdemon wrote:
| Wagile brother. It's a mix between agile and waterfall.
|
| Waterfall is great for high level governance (such as
| specifying high level milestones). Agile is great for executing
| on the deliverables.
|
| It is jus my experience. You're miles may vary.
| randcraw wrote:
| Of course there's a range of transitional states between
| waterfall and [whatever miracle cure is in vogue today]. Like
| all historical revisionists, today's techies like to impugn
| the old and laud the new. ('How could _they_ have been so
| clueless? ')
|
| Fact is, long-lived products, esp. from BigCorps, and esp.
| those in heavily regulated spaces like medicine and
| transportation always have and always will spend a lot more
| time and effort on design and process than will ephemeral
| products and services from startups. My software career
| started ca. 1990 just as waterfall was evolving into the
| 'Spiral' iterative software model, which since has been
| rebadged and remorphed several times into today's 'agile' and
| 'test-driven' gift from god. However in the real world,
| makers of every S/W product inevitably must adapt their
| actual development process to suit the lifecycle needs of
| their product and customer, in ways that scrum can't serve.
| Often the best way to reduce technical debt is to increase
| investment design and testing. And taken to NASA-like limits
| of fault-tolerance and reliability, that can take you all the
| way back to waterfall.
| minkles wrote:
| We use extreme waterfall. All the disadvantages of agile and
| waterfall in one process. Nothing gets to production due to
| meetings so the customers are happy we aren't fucking
| anything up.
| dehrmann wrote:
| The whole strawman/dichotomy you see with Agile and Waterfall
| boils down to needing both flexibility and vision for large
| projects, and each fails at one of these.
| kermatt wrote:
| Agilefall.
| bee_rider wrote:
| So like a waterfall, but the day to day is connected by
| little bits of agile? You end up at the bottom of the
| waterfall, but by taking a bunch of much smaller falls
| instead?
|
| Have you considered calling it Rapids development? You will
| sell a million books or whatever, just on the name.
| freetanga wrote:
| This. Some products are platforms with thousands of
| functionalities all interlinked in a uniform data model, with
| similar but specific behavior expected for all modules of the
| platform.For instance, a Core Banking System, or OMS in
| Telcos. And since we all get paychecks, it seems to work.
|
| Building such an product in agile was often tried and failed
| in the past decade. You need common data structures and
| routines that a few thousand developers can all expect to
| find ready further down the line. Like the Oregon Trail game,
| you launch all workstreams in different moments and expect
| them to converge at the finish line.
|
| I think "100% waterfall" was ditched in the early 90s, for
| all the known reasons, with smaller cycles of releases
| becoming the norm. But still the hard thinking, laying down
| the key mechanisms of a platform was heavily thought out
| early on.
|
| I think all criticism is a bit unfair, as agile is also an
| infinite source of cock ups, mediocrity and dead ends just as
| waterfall. There is a space for each approach, and bottom
| line, the right people will make all the difference. But
| that's also why it's important to learn and respect both
| approaches...
| jollyllama wrote:
| Indeed. Every real-world practice of development can be placed
| somewhere on the sliding-scale between Waterfall and Agile.
|
| One of the reasons that waterfall was a reasonable way to
| proceed was that, in the past, tighter coupling to hardware and
| longer hardware lead times meant the need to design and specify
| in advance. This is still somewhat the case where these
| conditions are true, albeit to a lesser degree.
| wpietri wrote:
| Yeah, I think the Waterfall model is what naive non-experts
| want from a project. I say what I want, you build it, it's
| delivered on time and on budget, and we're done.
|
| But I think it's basically a fairy tale. "And they lived
| happily ever after" for executives. And I can prove it. There
| are basically no successful products that started with an
| executive idea, were created in a waterfall fashion, and then
| stayed at that initial version forever. Waterfall is built on
| the fantasy of managerial omniscience, where the people in
| charge know everything important on day 1. But the reality is
| that the beginning of a project is when we know the least.
| Waterfall in practice is a bet nobody will learn anything as
| time goes on. And on waterfall projects, that often turns out
| to be true, if only because course corrections would cause
| executives to lose face.
| dannyobrien wrote:
| I too worked on waterfall dev projects. It was a nightmare and
| did not ship. The Agile Manifesto was a breath of fresh air,
| just because it captured what a lot of people were thinking in
| a way that was coherent enough to present to managers as a
| viable alternative.
| tgv wrote:
| I joined a company that had adopted "agile" (in reality scrum +
| 2 week sprints) after a dramatic waterfall failure. They had
| attempted to rewrite a good, working, profitable product and
| had spent 2 years on the designs, only to throw it away because
| they just couldn't get it completed.
| eweise wrote:
| On scrum projects I've been on, its essentially the waterfall
| model. Business comes up with a product and date, product and
| engineer give high level estimates. Program manager creates a
| project with all the stakeholders, product managers then write
| requirements, engineers then write designs. Finally this gets
| translated into jira epics/stories so engineers can do the
| implementation. The implementation runs in sprints so engineers
| can feel like they are doing agile. Finally when its all done,
| there's manual end to end testing with product and engineering.
| FartinMowler wrote:
| Agreed! There's waterfall & agile and dogmatic & pragmatic.
| I've never worked on a dogmatic waterfall project but have
| worked on several dogmatic agile projects (that made me
| strongly wish I wasn't).
|
| In the pragmatic waterfall projects I worked on, during the
| Design phase there was still coding (by juniors, on submodules
| with obvious predictable designs as well as some refactoring
| (yes!)) and testing going on. It's just that in the Design
| phase it was understood any coding might need to change. In the
| Code/Build phase, design changes were still possible as issues
| were discovered (with maybe just a little more resistance). In
| short, we were very pragmatic about it. Much more so than with
| the Agile religion.
|
| The Design phase focused on designing but not exclusively so.
| The Build phase focused on building but not exclusively so.
| Humans were building things long before Agile came along. The
| pyramids were probably built with a pragmatic waterfall method,
| not an agile method (pragmatic or dogmatic).
| ChrisMarshallNY wrote:
| Hardware development is almost exclusively Pragmatic
| Waterfall. It's pretty much a requirement. Lots of reasons.
| Too many to list here (it would probably not be useful).
|
| As a software dev for hardware companies, most of my life, I
| splashed in a lot of waterfalls.
| fzeindl wrote:
| What is less known is that the author of the waterfall model
| Winston W. Royce recommended doing the entire process TWICE:
|
| https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a...
|
| It is hard to foresee how the world of development would look
| like today, had companies used the waterfall process twice on
| each project.
| 2OEH8eoCRo0 wrote:
| That's how I did waterfall. We would go through all the
| requirements, group things that were related, and assign them
| to a developer who owned them. Repeat until there are no more
| unsatisfied requirements.
| oneshtein wrote:
| Many successful rewrites are Waterfalls, regardless of method
| used for first time.
| AnimalMuppet wrote:
| By the second time, you actually have a reasonable chance of
| knowing what the requirements _should have been_ the first
| time. They might even be valid for the rewrite, if things
| aren 't moving too fast.
| trustno2 wrote:
| What is TOGAF
| codeulike wrote:
| Back when Linkedin would let you Endorse people with random
| skills, Endorsing with "Waterfall" was such a fun diss
| ghaff wrote:
| The bottom line is that (for many cases) you want to take
| advantage of the mutability of software while not just winging
| everything on the fly. There's probably a reasonable medium which
| will differ depending upon the use case.
| pram wrote:
| It's funny because I had to take a company mandated 2 day Agile
| training class, and I thought the exact same thing. I thought
| "Waterfall" was just some concocted fantasy workflow to contrast
| with. I actually asked our instructor if it was real and he said
| "Of course it was!"
|
| Now I don't know what to think!
| bigstrat2003 wrote:
| It not only _was_ real, it still is real. Government in
| particular loves waterfall.
| bluGill wrote:
| Waterfall was named as a strawman. However it is very similar
| to what a lot of projects do. No project does waterfall as
| described because there are always things that can't work that
| way. (some projects get closer to waterfall than others)
| siva7 wrote:
| When people talk about Waterfall Model they forget the context of
| the era it originated. I've worked on a waterfall project early
| in my career. Please keep in mind that back in the 90s most
| software companies didn't have CI/CD, there was no cloud,
| releases were hand-delivered to the customer and usually rolled
| out about every 6 months because technically agile wasn't
| possible yet for most software shops. Waterfall was a valid
| method back then due to the technical (and cultural) limitations.
| datavirtue wrote:
| Users also expected stability and a lack of regression.
| Stakeholders simply didn't want or demand a new version every
| week.
| bluGill wrote:
| Haven't lived back then I'm not sure today's CD is better.
| Too often web breaks features people rely on. Worse they just
| do it randomly with no notice and no ability to have a
| transition time while you update. I miss the stability of
| knowing things will work like they did for a long time and
| when they break it is at a time I choose to apply the
| upgrade. (it didn't always work out this way, random bugs
| were a thing and still are)
|
| Quality control was also a lot more important - you couldn't
| ship something with many bugs as customers would be forced to
| look at competitors if they hit your bug.
| satisfice wrote:
| The problem of Waterfall didn't arise in the initial paper. It
| arose in subsequent interpretations. Particularly, see Parnas'
| classic paper arguing that we should pretend to follow the
| "right" practices [which he defined as essentially Waterfall]
| even if we didn't.
|
| I call this Parnism. It's Parnism we should fight, not Waterfall
| as such.
| rossdavidh wrote:
| I worked at a place where, while it was never called "waterfall",
| it was absolutely the way things worked. I think it naturally
| evolves this way:
|
| 1) a software project, when finished, turns out not to fulfill
| all of the things people wanted
|
| 2) "we should plan more carefully next time, so that all the
| requirements are identified at the beginning"
|
| 3) the next software project starts to resemble waterfall, but
| still misses some requirements
|
| 4) "we should spend more time on the requirements phase next
| time, so we don't miss anything"
|
| 5) etc.
|
| It is the natural method that large organizations end up with, in
| the absence of any philosophy saying otherwise. It's not the
| natural method that startups or small organizations end up with,
| probably, because it involves a ton of meetings first, before
| anything is done, and that is something that happens more in
| large organizations.
|
| Waterfall is what you get when it is always the safer option to
| say, "wait, let's spend more time planning out and getting buy-
| in". There may not be many places that call it "waterfall", but
| there are a lot of places that do it. Some of them even call it
| "agile".
| quantadev wrote:
| The way you can tell you're in one of these dysfunctional
| companies in my experiences is at the moment you, as a software
| developer, have to attend TWO meetings in one day. Companies
| that have too many meetings tend to have middle managers with
| only one goal for all these meetings: "Covering their ass."
| They treat these meetings as a way to collect evidence to be
| used later to prove that they weren't at fault when the project
| fails to meet it's objectives.
| aidenn0 wrote:
| I'd say more than 5 meetings a week for an IC rather than two
| in a day. (I have 3 meetings a week, but two of them are
| coincidentally on the same day). Managers will naturally have
| more meetings.
| quantadev wrote:
| I agree, you're right. I didn't think of it that way
| because most agile teams have a mandatory scrum meeting in
| the morning every day anyway. So a meeting is always
| literally the first thing you do...or at least it's your
| first interruption that comes right about the time you
| begin concentrating.
|
| It's super counter-productive too because in the morning is
| when I'm at my most productive and a guaranteed
| interruption every single morning is horrible.
| aidenn0 wrote:
| > It's super counter-productive too because in the
| morning is when I'm at my most productive and a
| guaranteed interruption every single morning is horrible.
|
| At least in my bubble, tech seems to be skewed heavily
| towards night-owls. I winder if putting the meeting in
| the morning is due to people assuming that, since they
| aren't productive in the mornings, neither is anybody
| else.
| Supermancho wrote:
| After you have 10 years of institutional knowledge, you'll
| get 1 meeting per various projects, including some of those
| you _used to be a part of_.
| Lutzb wrote:
| I have never seen waterfall in pure form. Mostly some kind of big
| upfront requirements projects with implementations iterations and
| a lot of project change management during the dev phase. These
| upfront requirements periods could be anything from a couple of
| weeks to a couple of years. While, I don't doubt that long
| requirements phases can have some value in aligning stakeholders
| on a new direction, they often became a raison d'etre for
| complete teams - often stopping other promising projects in its
| wake: "You have to align with project jabberwocky before we can
| sign off your project." Agile seemed like a way to start early
| and get reduce the inherent waste by building software on paper
| upfront.
| Zigurd wrote:
| I don't think this post is quite accurate that Royce proposed the
| model just to critique it. Royce's 1970 paper describes a way of
| adapting normal project management practice to software.
|
| Royce's criticism of the model touches on the brittle nature of
| specs in the face of discoveries about performance that mean a
| project could potentially have to start over.
|
| Agile, however, has a lot more solid basis in the difficulty of
| estimating software development tasks. Using traditional project
| management tools, you would do a resource-leveled critical path
| analysis, which is a very heavyweight way of optimizing who does
| what and when, which then within a couple weeks is no longer
| useful because your task estimates suck. Instead you get. the
| team together every couple of weeks and decide who does what.
| Rinse and repeat.
|
| Agile works better because estimates almost always suck but
| that's OK because that doesn't break your exquisiite schedule
| analysis because you're not making one.
| replyifuagree wrote:
| Yep and here we are in 2024 and just this last week I got into
| a heated discussion with an 'Technical' Program Manager raging
| about how the deliverables are slipping by three days mostly
| because he and his up chain are heavily invested in a schedule
| that is built on hope. Not only are the estimates bad, but the
| resourcing from the different silos has not happened either, so
| there is tons of unfinished work just on the work that is
| known, let alone the unknown unknowns!
|
| Next up he's about to find out his integration timeline is
| complete and utter bullshit.
| beastcoast wrote:
| Time to get a new TPM. Any TPM worth their salt should be
| doing everything in their power to catalog and mitigate those
| risks, and communicate them upwards. Lack of communication in
| both directions and adversarial conversations with engineers
| is a whole parade of red flags.
|
| That said, Gantt charts absolutely have their place alongside
| Agile. Our budget and goals are set yearly so inevitably
| there's going to be milestones and work back dates to meet,
| as well as cross-team/org dependencies to track.
| vegetablepotpie wrote:
| Waterfall is a straw man, early descriptions by Royce were
| written specifically to criticize it. Waterfall is mentioned in
| relation to agile to sing agiles praises. No serious developer
| will claim to use waterfall.
|
| There are however, a suite of _scientific management_ approaches
| based on the work of Henry Gantt which have been used, and are
| used today, that fit under the umbrella of _waterfall_
| approaches, such as the program evaluation and review technique,
| critical path, critical chain, and earned value. These are still
| in use today, and in fact government contractors are legally
| required to use earned value for acquisition programs over a
| certain value.
| oneshtein wrote:
| Waterfalls are good for rewrites, e.g. from Python to Go,
| because problem/solution territory is explored already.
| neilv wrote:
| Two situations that Agile is great for:
|
| 1. You're a contracting house, your clients are hopeless, and you
| just want to start billing hours, and keep billing hours every
| 1-2 uninterrupted weeks of peace. Clients saying something
| different every 1-2 weeks is no significant harm done, since you
| don't have to care, you just want to keep billing hours.
|
| 2. Possibly in-house rather than contracting, stakeholders and
| developers collectively have little idea what they're doing,
| whether in the problem/system domain or in process, so planning
| is mostly pretend and counterproductive, and best minimized. Just
| do _something_ now, and everyone will quickly see whether it
| looks in the right direction. And where this model breaks down,
| you can duct tape it with firefighting meetings that have some
| people looking like heroic decisive leaders with a bias for
| action (win).
|
| That's fine, but these people should quietly enjoy their Agile,
| keep their heads down, and stop trying to evangelize Agile to
| people who don't have (or are getting rid of) either of the above
| two dynamics. Also, if they find themself saying "Waterfall",
| that's probably a reminder that they've accidentally started
| evangelizing, and in a parroting way.
| badgersnake wrote:
| I think what you're trying to say is that there is no one
| development process that fits every situation because all
| situations are different and thus what you need to do to have a
| successful software project is adapt the process to the
| business and do what works.
| pyrale wrote:
| > these people should quietly enjoy their Agile, keep their
| heads down, and stop trying to evangelize Agile to people who
| don't have (or are getting rid of) either of the above two
| dynamics.
|
| I disagree. I've seen more than my fair share of people signing
| on "big" IT contracts that promise nothing except
| specifications before Y+2 or Y+3, and these people need to see
| the light. To date, I have never seen any multi-year software
| project that doesn't start delivering early land softly. And
| whenever they crash, it's the teams that suffer.
| neilv wrote:
| OK, they should limit themselves to evangelizing to dynamics
| #1 and #2. Something like:
|
| 1. "You people only care about billing hours, and Agile is
| how you do it nicely."
|
| 2. "This/these organizations are systemically incapable of
| coordinating effectively on something like this, so Agile is
| probably your best bet for eventually reaching a passable
| solution, and reassuring people in the meantime."
| tboyd47 wrote:
| 3. Hot shot VP in non-software company starts a small in-house
| software team that immediately has to manage multiple
| small/intermittent software projects where the product owners
| are half not paying attention / half don't care, and the team
| just wants them in the room at least once or twice a week.
|
| This drama has played out in almost every company over a
| certain size in America I'm sure
| llm_nerd wrote:
| I feel like this post has some nuance or clever wordplay that I'm
| missing. So if that's the case, apologies for adding noise.
|
| But in the real world, the waterfall model was absolutely not a
| "strawman", but instead was literally how almost all software was
| built, up to even the turn of the century and beyond. Software
| projects were smaller in general, compiling was a major
| undertaken, you collaborated on projects by sending files around
| or, best case, working on a shared network directory. The pace of
| change of tooling and "libraries" was much slower and more
| predictable.
|
| As we got source control, intellisense, massive knowledge bases,
| and then the rapid iteration of code sharing in the form of
| libraries and so on, things started changing because the model
| was too slow. But it was absolutely real and the norm.
| torginus wrote:
| Yeah this is strange how every agile coach has a sales script
| that begins with extolling the evils of waterfall.
|
| It's far more likely that the customer/boss adds features and
| requirements way late in the process. As an anecdote, I was
| working on a small mobile app, and two days before release date,
| my boss came in and demanded that I make the app work on ancient
| iPhone's with tiny screens, which involved having to redesign
| large parts of the UI to reflow in ways I hadn't thought of. He
| justified this by being 'agile' and 'forward thinking'
| aa-jv wrote:
| Plenty of people have written books that confirm/deny the
| efficacy of the Waterfall model.
|
| But in the meantime, there are far, far many more folks - by
| significant orders of magnitude - who have written _software_
| with the Waterfall model.
|
| Far, far more.
|
| The fact that it is still with us, and can still be used _quite
| effectively_ sort of leads credence to the idea that those who
| can, do, while those who can 't, teach (or write books about it).
| pyrale wrote:
| I fail to follow the logic from the author:
|
| - there is this thing called "waterfall"
|
| - author agrees that there are people that actually use it as a
| methodology for their software projects
|
| - But because no one wrote a book about it, author assumes
| talking about "the waterfall model" a strawman.
|
| To me, this sounds like moving the goalposts. One comment fits my
| experience :
|
| > The Waterfall model IMHO comes from Taylorism. Is a serial
| assembly line that follows an strict division of labor,
| management that thinks and workers that execute, etc. Having
| worked with professionals beyond sw development, they don't call
| it "Waterfall" but it is everywhere.
| datavirtue wrote:
| Especially in agile.
| pyrale wrote:
| I do agree that there is a thriving industry dedicated to
| finding ways to brand whatever process management currently
| uses as "agile".
| samatman wrote:
| Was it?
|
| What if I had a smoking gun?
|
| https://www.product-lifecycle-management.com/download/DOD-ST...
| 23B1 wrote:
| I'm sorry... what?
|
| The waterfall method is EVERYWHERE, entrenched, systematic, and
| pervasive. Even when you're supposedly doing Agile, there's
| always half the team still thinking in waterfall.
|
| In any non-digitally-native company, including many F500s,
| waterfall still happens, is still happening, has always been
| happening, will likely continue to happen.
|
| And you know what? That's okay. Choose the tools that fit the
| job, not fit the job to the tool.
| tboyd47 wrote:
| Why do you think it's more prevalent in non-digitally-native
| companies? I've often wondered if it's because those companies
| are uncomfortable with software development in the first place,
| so it makes them feel better to have a finish date for the
| project.
| ebiester wrote:
| I dive into this in my blog, "What is your alternative to Agile?"
| - https://www.ebiester.com/agile/2023/04/22/what-agile-alterna...
| - but the Structured Systems Analysis and Design Method as well
| as PRINCE2 were common in the industry, but both were examples of
| methodologies that took waterfall and codified it. However, the
| last waterfall project I was on was in 2013. We had formal gates
| out of each section of the process. (Even there, we tried to make
| it as incremental as possible, but it was a Fortune 500 company
| that had an overarching process.)
|
| You also have to remember that there are a lot of software
| projects that do have a "done" state, after which the project
| goes into maintenance until there is more funding for
| improvements. Consider an internal project to turn a department
| excel sheet into an application. You can quickly reverse engineer
| the current behavior, go to the stakeholders and get a set of the
| desired behaviors above and beyond what the spreadsheet does,
| negotiate a scope, write a small design document, and just go do
| it. You then demo it at the end and change what is necessary
| before they start using it. You have a small set of bug fixes and
| QOL improvements that follow, then the project is handed off to a
| team managing 500 similar projects overseas and is responsible
| for security and bug fixes.
|
| This doesn't make sense in product companies for good reason.
| However, on small projects, waterfall can work.
| jillesvangurp wrote:
| The Royce paper is actually still worth reading. It's well
| written and if you can step over the 50+ years of history since
| then also still somewhat informative. And of course the word
| waterfall doesn't actually appear in it. That word was slapped on
| it by others afterwards. And of course Royce vaguely suggests
| that going through the steps more than once might be helpful.
| What we now call iterating.
|
| The key concept for what we now call agile (which mostly boils
| down to variations of scrum these days) actually has roots dating
| back about half a century. People were suggestion spiral
| development at some point (converging on some final thing) as
| early as the eighties. There was the whole 4+1 model which got
| caught up in the whole UML movement and it's associated process.
|
| The key innovation that extreme programming (one of original
| agile methodologies) brought was that increasing the iteration
| frequency and giving up on the notion that you can do a lot of
| requirements and design up front. Things change. Every iteration.
| So having a lot of requirements and design documentation to
| update every cycle is counter productive. Dropping that was
| considered extreme. But then people realized that that worked
| just fine and that these designs were kind of low value artifacts
| to begin with. Not really worth the hassle.
| gspencley wrote:
| The irony is that the proposition that "someone wrote a book that
| proposed waterfall as the best software method" is itself a
| strawman argument.
|
| To my knowledge, that has never been claimed.
|
| Waterfall is what many of us old fogies in the industry
| experienced as the "defacto" methodology for a long time. It made
| intuitive sense that in order to design a build a project that
| you would first, you know, DESIGN it. Then you'd kick over that
| design to software developers that were expected to implement it.
|
| Iteration in the design and development process, the idea of
| "people before process" and getting designers and engineers to
| collaborate early on etc. was not obvious. That's where all of
| Agile's "waterfall" talk came from. The fact that for a long time
| what companies were doing, while never exactly the same process
| as each other, was always waterfall-like because that's what made
| the most sense in an industry that was very new and in which no
| one knew wtf they were doing... so they took knowledge from other
| domains and tried to make it fit. That's a large part of what
| Fred Brook's The Mythical Man Month talks about.
|
| It's only now that a new generation of developers has come up in
| a world where all they've ever known was "Agile" and "Scrum",
| that the world they know is so far removed from the "non-Agile"
| world that these books describe.
|
| A colleague of mine the other day was talking about experimenting
| with something using the browser's `postMessage` API 8 years ago.
| My initial reaction was "did postMessage exist 8 years ago?" And
| then I remembered that 8 years ago was 2016 and it's already
| 2024. Many "experienced" people coding today have 5 years
| experience... and then they talk about concepts that were a
| reaction to how things were being done in the 80s and 90s as if
| those decades never happened ... because if they had even been
| born yet they were still children, so they weren't there to live
| that reality and the pain that what came later was a reaction to.
| colechristensen wrote:
| "Waterfall" is just a pejorative term used against the kind of
| project management that uses a Gantt chart, which kinda looks
| like a waterfall. This kind of project planning is necessary
| when you've got engineering steps that are time sensitive and
| take months to years. Like if you're building a large bridge
| you need to schedule the resources to do individual steps a
| long time in advance.
|
| Writing software was initially run like this and there was a
| big pushback because most of those old school engineering
| methodologies just aren't justified because when you're writing
| software all of the steps look pretty similar and the
| design/build/test cycle can go through a full cycle in minutes
| instead of years and you get to do it millions of times instead
| of, like for a bridge, only once.
|
| Those engineering practices are still necessary when you're
| building things, sometimes a bit less so with electronics
| hardware these days we have prototyping that can turn around
| very quickly, but still if you're doing a large physical
| engineering project, you do lots of "waterfall" because that's
| the best tool for the job because the job requires it.
|
| https://en.wikipedia.org/wiki/Gantt_chart
| bunderbunder wrote:
| I'm guessing the "book" in question would be something akin to
| https://en.wikipedia.org/wiki/DOD-STD-2167A
|
| Which, given that that's a military spec, also speaks to a
| motivation for such a tightly controlled approach: the cost of
| design changes is truly immense. When you have a large
| government project with MANY different contractors working on
| different pieces of the system, a lot of Agile principles need
| to go out the window. The spec needs to be fairly well nailed
| down up front because a late change that affects adjacent
| systems gets really expensive when those adjacent systems are
| being managed by a completely different company. That
| requirements tweak may now be a full on contract renegotiation.
| And, as Boeing's recent woes illustrate, communication among
| all the subcontractors may be so poor that even identifying the
| potential impact of a specification change may be difficult to
| do reliably.
|
| Not such a big deal in a lot of tech projects where it's
| relatively inexpensive to solve problems as you find them. But
| Mars rovers don't get to have canary deployments.
|
| Also, even then, it's still not really "textbook" waterfall.
| HeyLaughingBoy wrote:
| > designers and engineers to collaborate early on etc.
|
| The really scary thing to me is that I'm old enough to remember
| when all the trade rags were excitedly talking about how it's a
| great idea to not just "throw your design over the wall" but
| work with the software guys to understand what their needs were
| and accommodate them.
|
| The scarier thing is that they were talking about this in the
| year 2000.
| bunderbunder wrote:
| Royce's paper is one of the best pieces on how to manage software
| projects that I've ever read. It's quite short, but every time I
| re-read it I notice a new insight I hadn't noticed previously.
|
| Royce did not present that waterfall diagram as a straw man. The
| structure of the paper is itself rather agile: he starts with the
| simplest thing that could possibly work, identifies problems with
| it, and then progressively iterates on it.
|
| That certain people in the Agile community continue to perpetuate
| the myth that this model is a serious thing that people actually
| thought was a good idea might be a straw man. But ignoring the
| rest of the paper is probably good strategy. That one page is a
| useful starting model for them, too. But they _really_ woudln 't
| want to call attention to any other page of the paper. The rest
| of the pages are too full of hard-won observations that speak to
| why Scrum seems to work out so poorly in practice for large,
| multi-team projects.
| StellarScience wrote:
| 2+ decades ago, US Air Force acquisition classes taught exactly
| this method. I don't recall whether they used the word
| "waterfall", but they showed the same diagrams and treated
| software development like massive hardware projects, such as
| building an F-16: first you write a long requirements document,
| then generate a voluminous design document, then break the design
| into a work breakdown structure, farm out component
| implementation to developers, then finally integrate, test, and
| ship. It borrowed heavily from the field of Systems Engineering.
|
| In my experience it never worked. We were able to achieve success
| only by secretly ignoring the rules and process and instead
| developing software in what detractors called a "cowboy" process.
| When "agile" came out, it changed our lives. We adopted a few new
| good ideas, but mostly kept working as we had been. But now we
| could point to this quasi-official "agile process", with
| tailoring as they recommend. As long as we were following a
| process, and not being "cowboys", folks seemed satisfied.
|
| These days the Air Force has caught on to "agile". They even have
| 400-page manuals on the process to follow to be "agile"! We still
| cut some corners here and there and do what we think makes sense,
| but there's far less process push-back than there was in the
| past.
| Jtsummers wrote:
| Acquisitions didn't use Waterfall that I ever saw, until you
| got to the software specific courses. Then they did, and it was
| one of several software development lifecycles you were allowed
| to choose between for projects.
|
| Many program offices and project managers selected it because
| it was pretty, not because it was sensible.
|
| > These days the Air Force has caught on to "agile". They even
| have 400-page manuals on the process to follow to be "agile"!
| We still cut some corners here and there and do what we think
| makes sense, but there's far less process push-back than there
| was in the past.
|
| Circa 2010 (+/- a couple years) USAF also picked up Lean in a
| big way. But their version of Lean was almost exactly the
| opposite, in practice, of what was done and described by
| industry as Lean. A key element of Lean being that you actually
| let the people doing the work provide feedback and direct
| improvement efforts. USAF's version had the managers (who never
| did the work) walk around and observe, then change processes to
| be "leaner". That is, pure scientific management in the
| Taylorism style.
|
| USAF is a great place for good ideas to get their names reused
| for old ideas.
| Jtsummers wrote:
| Replying since I can't edit it this far out:
|
| > Acquisitions didn't use Waterfall that I ever saw
|
| I mean, the _term_ Waterfall. It definitely had the structure
| of Waterfall.
| moandcompany wrote:
| Waterfall concepts were codified into MIL-STD-498 (1994) which
| was the basis for DoD (and NASA)'s Systems Engineering
| processes.
| jmward01 wrote:
| I'd argue that designing an aircraft still fails badly with
| waterfall and it is a major reason that aviation is massively
| behind where it should be right now. Space-x shows that you can
| build rockets, a lot better, if you ditch that waterfall
| process.
| opk wrote:
| When I was studying in the late 80s / early 90s, the text books
| contrasted the "old" waterfall approach with the more "modern"
| iterative approach. That was long before Agile or whatever had
| been invented and recognised that there needed to be a feedback
| loop.
|
| Trying to promote agile/scrum/xp/whatever by attacking waterfall
| is a straw man argument in my view because it is not comparing
| against what came before. That's not to say that clueless
| managers don't still like to reinvent and impose what is
| essentially waterfall.
| ineedasername wrote:
| The author is fortunate to have so few encounters with this IRL
| because there is a world of difference between "I have never seen
| a book propose this" and encountering it in practice.
|
| To my misfortune I have been involved in multiple ERP
| implementations where such require heavy customization &
| development of custom & bolt-on modules.
|
| This model wasn't explicitly presented in this visual style but
| it was the approach. Requirements were set nearly in stone even
| as business needs changed during a multi-year project. The result
| was systems people avoided using, creating shadow systems or
| surprising IT with "we bought this and need it integrated".
| shahzaibmushtaq wrote:
| The Waterfall Model had its time and piece of the pie (still has
| in the form of modified Waterfall models) at the beginning of the
| software development era when software was complex in nature.
| Therefore, time spent early reduces costs at later stages e.g., a
| problem found in early stages is cheaper to fix than later in the
| process because the software has to be embedded in the hardware -
| no software updates.
|
| We all know that it's not easy to find a good software engineer
| back then, or a knowledge center (like we do now) to get help
| from. If one team member leaves in the middle of an ongoing
| project for whatever reason, good documentation must be there for
| the new member to get a complete understanding of what's going
| on.
|
| The Waterfall Model was never perfect, and Royce never claims it
| is. Instead, he himself pointed out major flaws such as testing
| only happened at the end of the process.
|
| One thing I want to add is that Royce didn't use the term
| Waterfall but he said something like downstream. And he was right
| because we all know that speed of water is very fast but in this
| model it's too slow. Perhaps that's why he proposed modified
| versions of the original Water fall model
| https://www.researchgate.net/figure/Royces-modifications-of-...
| moandcompany wrote:
| I wish that discussions of Waterfall, "Agile," etc, and
| systems/software development methodologies would spend more time
| considering the motivations and rational reasons for why the
| process approach was created. The practice of systems and
| software engineering has existed longer than many of us have been
| professionals, and in many cases longer than many of us have been
| alive.
|
| The "Waterfall" systems (or software) development model was
| developed to reduce the likelihood and impact of requirements or
| specification changes over its development lifecycle. Likelihood
| and impact are elements of "risk," and the process can be seen as
| part of risk management. Rephrased, the Waterfall development
| methodology as a process was intended to help ensure that the
| system being developed (and delivered) was the correct solution
| (i.e. "valid") for the problems considered, and that the process
| of getting there would have the best known and acceptable costs.
|
| With any instance of a development process, there are risks of:
| Not getting the requirements or specifications correct (i.e.
| Failing to understand or solve the actual problem), Completion
| delays due to time spent on re-design or re-implementation from
| revisions to requirements or specifications, Completion cost
| overruns (i.e. delays) due to re-design or re-implementation,
| etc.
|
| The Waterfall process approach was eventually codified into
| things like MIL-STD-498 (https://en.wikipedia.org/wiki/MIL-
| STD-498) for software development. Waterfall is not specific to
| software development, and some lessons ingrained in the process
| came from disciplines where the cost of misunderstood
| requirements, changing requirements, or incorrect specifications
| are higher. Examples could include the design of a bridge,
| building, space launch vehicle, network communications systems,
| etc. In these cases, the further you go into development, the
| more costly ambiguity and/or errors in understanding the problem
| become.
|
| Unfortunately, as seen with many "processes," strict adherence to
| process or ritual without understanding or sanity checking what
| is being practiced against the rationale or purpose for those
| processes leads to poor outcomes. This is what the authors of the
| Agile Manifesto were responding to, and ironically the negative
| pattern of adherence to process without understanding why has
| replicated itself with modern practice of "agile" -- That is a
| human behavior and organizational culture problem.
| cbsmith wrote:
| I love realizing that I'm old enough that people think that
| practices that were the norm at the start of my career don't seem
| credible even a decade ago.
| steeeeeve wrote:
| All project management is terrible when you are following it
| blindly and have no understanding of what it takes to succeed.
|
| Waterfall works when it's done right in the right environment.
| It's a nightmare when it's not. Agile works when it's done right
| in the right environment. It's a nightmare when it's not.
|
| Having a good project manager who understands what it takes to
| succeed from a management/executive perspective and who
| understands how to keep engineers both productive and happy is
| priceless.
|
| During the waterfall days, you would run into managers who would
| gannt everything and harass people into meeting deadlines for
| whatever would solve the 8 word description of the item on the
| chart. These days, you run into managers who are happy to
| distribute a jira ticket to resolve anyones gripe.
|
| And then there are the thoughtful ones who understand priorities,
| factors for success, and how to set reasonable expectations on
| both sides of the table (for the techies and non-techies)
|
| In the end, it's not the process you follow, it's the results
| that matter.
| Hasu wrote:
| > In the end, it's not the process you follow, it's the results
| that matter.
|
| I was nodding along with this post up until this last sentence.
|
| Yes, the results are what matter, but process is what drives
| the results. It is thus critical to the success of a project to
| ensure that the process is appropriate.
|
| For example, the entire purpose of agile is to have short
| iteration cycles where you deliver to customers and get
| feedback before starting the next cycle. If you have a product
| where you cannot get feedback, agile is a bad solution! You
| will deliver every two weeks - and then continue to do what you
| would have done anyway. That makes all the agile ceremonies
| quite the waste of time.
|
| Conversely, if you ARE getting feedback regularly it's insane
| to do waterfall when you're two weeks into a 6 month project,
| and the customer doesn't like what you're showing them.
|
| This can get a lot more detailed at the micro-level for
| managing process on teams - there are tradeoffs between
| developer happiness, speed, quality, visibility, and many other
| axes that process can adjust, and a team that is set up with
| good process will be set up to execute better than one that
| isn't.
|
| I tend to be someone that is perceived to "hate process", but I
| don't, I hate bad process that is counterproductive to
| execution and achieving results.
| marcosdumay wrote:
| Yes, the person that invented that name did personally say he
| created it as a strawman and never saw it applied anywhere.
|
| At the same time, the waterfall model was the standard model for
| contracting software in large organizations until around the 10s
| (yep, 2010s), usually mandated by all kinds of compliance rules.
| survivedurcode wrote:
| Just because there was research from 1970 (as there was in
| subsequent years) showing that big design up front is a bad idea
| doesn't mean that waterfall is a straw man argument. It is
| probably necessary when you are shipping code with extremely high
| costs of operation, where mistakes are extremely expensive (i.e.
| missiles, space shuttles). I imagine automotive ECU software is
| probably in that category.
|
| The software industry has ignored research from 1970s and on and
| continues to ignore it today.
|
| Look at the microservices craze. It's another way that big-design
| up-front has been brought back.
| sevensor wrote:
| My most successful project management experience ever worked like
| this: we had a massive Gantt chart showing all of the work we had
| planned. I added and removed rows daily, updated expected
| completion dates, and generally rearranged the whole thing. The
| one thing that never changed was anticipated delivery date. Every
| week I sent the CTO a report with a snapshot and an explanation
| of what changed and why. I expected to get yelled at more than
| once, but he was happy with the sense of control, and the
| developers enjoyed the flexibility.
|
| It was exhausting and I'm glad I'm not doing project management
| in my current role.
| junto wrote:
| Almost twenty years ago I worked on a project where an external
| unnamed "big four consultancy" had written a very long document
| titled "statement of works" that had about 130 pages.
|
| It described a LOB application for a corporate customer in minute
| detail. Every form was described with the order of input
| elements, fonts and font sizes to be used, grouping of fields,
| you name it, it was there.
|
| We just followed the instructions exactly and after 15 months we
| delivered the finished application.
|
| These kinds of projects did exist but the specification and
| requirements phase was long and expensive.
|
| However it required the client to take the time to understand
| their current business processes and more importantly what they
| should be and how they wanted them to work.
|
| It was one of the most mundanely boring projects I ever worked
| on.
| stevenalowe wrote:
| Gated development cycles were/are common, regardless of what you
| call them. If the target is not moving too fast, the process can
| work. If computer time is vastly more expensive than programmer
| time, working 'offline' writing/checking specs is time well-
| spent. If you take the standard SDLC steps, apply them to the
| smallest useful piece of functionality, replace written specs
| with automated tests, you get a single-piece flow model which
| strongly resembles agile practices (but says nothing about agile
| philosophy).
| nomel wrote:
| I personally can't comprehend building software with the
| waterfall method. I always do a reverse waterfall: build the
| fundamentals at the bottom. They are the non-negotiable "truths"
| of the problem, representing something close to the minimal
| complexity. Then, tie them together to work _towards_ the
| relatively mushy end goal, with the abstractions being much more
| obvious as you work your way up, with a few "shifts" where
| higher level abstractions may pop out and collapse things into
| simpler pieces as you go up.
|
| I would consider the GUI being one of those "truths".
| fermigier wrote:
| In French, we call it "Le cycle en V" and we think it's
| beautiful.
| snapetom wrote:
| My first job in development was at a lending division at a bank.
| After that, I was at a large health insurance company.
| (1999-2005) Waterfall certainly did exist and it got even worse
| at the health insurance company. My official title was
| "Application Developer" but I spent about 60% of my time filling
| out reams of paper that got passed around in meetings with
| everyone under the sun that took another 20% of my time.
|
| The first time a startup recruited me and described how they
| worked, I jumped on that mainly because I'd actually be coding.
| worik wrote:
| I was explicitly taught the waterfall model in 1991 at a
| university computer science course
|
| I had to work out the problems myself
| ang_cire wrote:
| Every waterfall project was actually spiral or hybrid.
| atribecalledqst wrote:
| Reading this thread is bumming me out because it's made me
| realized my company USED TO have a good fusion between
| 'waterfall' and 'agile'. The requirements development phase,
| development, and testing phases were all very flexible and had
| feedback mechanisms as we gradually figured out The Right Way to
| get the thing to work.
|
| Systems, software, and testing all worked in close concert so
| that software developers could find problems or gaps in
| requirements, as could testers. And of course there was a strong
| feedback loop between software & test. Meetings were weekly and
| people reached out to each other as needed outside of that. A
| daily standup was usually a sign that something was wrong.
|
| In recent years we've moved to cargo-cult capital-A Agile, so
| we've basically traded our flexible process for a LOT more
| meeting overhead and pretty much a negative gain in efficiency.
| We spend significant portions of meetings talking about process
| which was never a problem in the past.
|
| All because we didn't fit some predefined one-size-fits-all
| framework... sad!
|
| (and of course the REALLY dumb thing, is that we're still often
| tied to a delivery schedule of 1 or 2 builds a year, with
| customer selloff testing - so the external process we fit into is
| still 'waterfall-y')
|
| e; I guess one thing I neglected to mention here is schedule. We
| usually never had issues with schedule, our timelines were
| generous enough that even if we underestimated the complexity of
| something we could still make the delivery date. (admittedly
| there would sometimes be crunch periods in the last few weeks
| before delivery)
| bulletmarker wrote:
| If you follow the waterfall process faithfully then you guarantee
| mediocrity in what you produce.
| readthenotes1 wrote:
| It would have been better if the author had used the flow diagram
| from the original waterfall paper that showed the backflows.
| mont_tag wrote:
| It was not a straw man. I've seen it specified in contracts. I've
| seen audit teams sent in to verify an SDLC (system development
| life cycle). Arthur Andersen (now Andersen consulting) had it
| formalized in their "Method 1" system development approach.
|
| Any semblance of agile was met with hostility. You were labeled a
| "cowboy programmer" or "hobbyist programmer" if you dared start
| with code instead of specification and approved plan.
|
| Also, it is easy to forget those "rules" weren't wrong. People
| were coding in non-agile languages. Version control tools had
| strict checkout and locking. Project communication was in the
| form of rows of three ring binders -- everytime you added or
| changed a function, you marked up the existing doc page and a
| secretary retyped it with carbon paper (for a subject book, title
| book, and subsystem book).
|
| Changed to requirements were _very_ expensive, so the whole
| system was designed to get full buy in a once. Consider that even
| now in this "age of enlightenment", we take a waterfall approach
| in nonsoftware projects simply because changes are expensive. If
| you're having a custom home built, you need to make a lot of
| decisions early. You're charged heavily if you want to change the
| spec during construction.
___________________________________________________________________
(page generated 2024-09-16 23:01 UTC)