Is there any big software corporation out there still practicing Waterfall?



  • Just asking. Every shop seems to swear by Agile, but even now in 2017, Agile proponents keep making Waterfall the dragon they desperately want to slay. It looks almost like a diehard commie explaining how good communism is compared to rampaging feudalism — in the 21st century.

    Not only the dragon seems made of straw, it's already torn apart, trodden on, and rotten away.

    Or is it not?

    Are there large software companies who still advocate the Waterfall model in 2017, for every kind of a software project? Does Agile still have a rival in Waterfall?


  • Java Dev

    @wft Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.


  • FoxDev

    @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    Most companies will be somewhere along the spectrum

    Agifall.


  • Java Dev

    @raceprouk Well, yes, you get companies which email out demands to 'fill in which bugs you will fix in sprints 27, 28, and 29 by next week'.


  • FoxDev

    @raceprouk said in Is there any big software corporation out there still practicing Waterfall?:

    @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    Most companies will be somewhere along the spectrum

    Agifail.

    fixed your spelling for you.

    :-P


  • And then the murders began.

    If you looked at the labels on our lifecycle, you could be forgiven for thinking we were still doing waterfall. But while we may not be "officially" using Agile or one of its cohorts, our mindset and release cadence are very much in the same place.



  • @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    @wft Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.

    Well, I'd like to hear from a company being on the side of spectrum where they do it in big phases. Big requirements, big design, big coding, big testing, biiiiiiig maintenance. In that order. Weekly or monthly status meetings and no sprints whatsoever.



  • @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    @wft Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.

    I actually worked at a company which did 98% of Scrum proper, back in 2009. The missing 2% was that we sometimes failed to timebox estimation meetings. Didn't feel micromanaged, retrospectives were fun, and the shit was getting done. I need to say — we were not so much Agile as we were agile, small "a".

    So yup, it can possibly work. But it takes bags of charisma from the team leader. They don't make people like that anymore.



  • @wft said in Is there any big software corporation out there still practicing Waterfall?:

    I actually worked at a company which did 98% of Scrum proper, back in 2009. The missing 2% was that we sometimes failed to timebox estimation meetings. Didn't feel micromanaged, retrospectives were fun, and the shit was getting done. I need to say — we were not so much Agile as we were agile, small "a".

    That's the only kind of agility that works. The actual kind.


  • Impossible Mission - B

    Dunno about big software corporations, but The Piano Guys sure seem to be into it:

    https://www.youtube.com/watch?v=8P9hAN-teOU



  • @wft Did any company that was practicing Waterfall call it "Waterfall"? I always assumed that term was invented after-the-fact to explain what people had been doing to that point.

    Also keep in mind that Agile and Waterfall are (in theory) not mutually-exclusive. An Agile team could still decide that Waterfall was the best arrangement for them to achieve the goal.



  • @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.

    Pure Agile is just "agility". Doing regular retrospectives and making changes based on those.

    You're probably calling either Scrum or Kanban "Agile". You can be Scrum without being Agile. (I've been on a team like that. Scrum was dictated from above, there were no retrospectives.) You can be Waterfall while being Agile.


  • 🚽 Regular

    I'd imagine banks, government, and large regulated institutions are doing waterfall, simply because every requirement has to be rubber stamped by someone before it can even start. Waterfall's perfect for bureaucracy and an agile workflow would collapse under it. But, I'm sure even that isn't 100%, since I'm sure someone reviewing a bank portal might call an audible and say, "Why don't we move that button to the right side?"

    Note: My understanding of waterfall is you do all the reqs first, which are set in stone, technical designs next, set in stone, then you implement the project. Which, to me, isn't agile.


  • I survived the hour long Uno hand

    @wft said in Is there any big software corporation out there still practicing Waterfall?:

    Big requirements, big design, big coding, big testing, biiiiiiig maintenance. In that order. Weekly or monthly status meetings and no sprints whatsoever.

    We were like this until our supposed transition to Agile this year. We're pretty much still like this. People don't see how you can start coding without knowing all the "requirements" including detailed Photoshop mockups of the screens ahead of time, and how you can test anything when there's still stuff missing. I've had to read 17+ page requirements documents before.



  • @wft said in Is there any big software corporation out there still practicing Waterfall?:

    Well, I'd like to hear from a company being on the side of spectrum where they do it in big phases. Big requirements, big design, big coding, big testing, biiiiiiig maintenance. In that order. Weekly or monthly status meetings and no sprints whatsoever.

    I had endless debates with a previous company that there's no way you could write a system to do tax-exempt spending account benefits (HSA, TSA, etc) and have something that could be demoed in 2 weeks. 2 months, maybe. Just breaking it into individual tasks of less than 1 weeks' work (the maximum allowed by their rules) that could be QAed independently was a challenge. It took us about 2 weeks to come up with the data structures needed, which was all "off the clock" according to the Scrum process, and even with that amount of time we fucked it up and had to backtrack a bunch later on.

    Scrum is useless for new development, if you're actually solving hard problems. It's great for maintenance development.



  • @the_quiet_one said in Is there any big software corporation out there still practicing Waterfall?:

    I'd imagine banks, government, and large regulated institutions are doing waterfall, simply because every requirement has to be rubber stamped by someone before it can even start. Waterfall's perfect for bureaucracy and an agile workflow would collapse under it. But, I'm sure even that isn't 100%, since I'm sure someone reviewing a bank portal might call an audible and say, "Why don't we move that button to the right side?"

    Yeah, no. The government can't make its mind up on which numbers need to be shown as positive or calculated as negative when. They'll change the requirements up until the week before the law goes into effect. Some of them they'll keep changing after the law goes into effect, because they haven't seen what the actual ramifications of the laws they make are.

    If you do waterfall on banking software, you are guaranteed to release software that breaks laws.



  • @blakeyrat I find the only way to do things like that is to do rough Kanban, where priority and flow are the only things that matter. Predictions are worthless for new development, which is all Scrum is about.


  • Discourse touched me in a no-no place

    @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    Scrum is useless for new development, if you're actually solving hard problems.

    I think it might be OK once you've got the basic skeleton of the app in place so that developing new things becomes just fitting new stuff in. But the basic structure is really hard to do without getting some requirements together and having a really hard think about how to go about solving them. I guess you could use a heavy hammer to wedge the square pegs of early-stage development into the round holes of scrum… but why would you? The skeleton shouldn't take all that long to design once the basic requirements are done.



  • @dkf said in Is there any big software corporation out there still practicing Waterfall?:

    The skeleton shouldn't take all that long to design once the basic requirements are done.

    The problem isn't the requirements (well, usually), the problem is the data structures. It's the same problem that "write your unit tests before writing code" has-- the data structures need to be set in stone before you can do any of the actual work, and complex problems have complex data structures. A lot of the time, you don't even realize your made an incorrect assumption on your data structures until after you're written some spec code for a few weeks and you have to go back to the drawing board.

    "Is this account attached to a applicant or a dependent? If the applicant has one, can the dependent have another? If the applicant has none, can the dependent have one? If they have account A, they can't have account B also-- how do we tell the relational database to enforce that? The description of this account has variables in it-- the dollar value of X depends on applicant's age, how do we template it? Even with nothing in our data structures to this point has needed to be templated." etc. Answering questions like those can take weeks and, for maximum reduction of re-work, has to be done before any actual code is written.


  • Discourse touched me in a no-no place

    @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    It's the same problem that "write your unit tests before writing code" has-- the data structures need to be set in stone before you can do any of the actual work, and complex problems have complex data structures.

    I usually find it is the relationships between data structures that cause the problems particularly. Slapping another simple field in there doesn't cause trouble most of the time, but adding another link between structures is potentially a really big deal. It's like adding another foreign key relationship to a database schema; caution required, every time. Also, applications that involve multiple security domains tend to need a lot more planning. Fixing a fuckup in the information partitioning required for making the security meaningful will truly screw development over.

    Many years ago, before I graduated, I acquired a book on Object Oriented Analysis. A lot of what is in that book was deeply broken (it used one of the predecessors of UML, for goodness' sake!) but the basic underlying ideas about how to partition an application and work out what the real data structures had to be, those continue to be useful.



  • @the_quiet_one I know for the fact HSBC has a sort of Scrum.


  • Discourse touched me in a no-no place

    @magus said in Is there any big software corporation out there still practicing Waterfall?:

    If you do waterfall on banking software, you are guaranteed to release software that breaks laws.

    Apposite:



  • @pjh Moral of the story: Don't do banking software.


  • BINNED

    @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.

    Pure Agile is just "agility". Doing regular retrospectives and making changes based on those.

    You're probably calling either Scrum or Kanban "Agile". You can be Scrum without being Agile. (I've been on a team like that. Scrum was dictated from above, there were no retrospectives.) You can be Waterfall while being Agile.

    Huh? I think you are dangerously close to be a manager. Now I know where managers come from.


  • Impossible Mission - B

    The most successful software team I ever worked on had no "agile-ness" whatsoever.

    Words like "scrum" and "kanban" were never even brought up. There were no daily 15-minute stand-ups; once a week we'd have a team meeting to go over various issues and make sure everyone's on the same page; it generally lasted 30-60 minutes. There were no unit tests; all testing was done by a team of testers. Feature sets and release schedules were dictated from on high.

    And it worked! We met those release schedules, we came out with good code, when the code wasn't good, our excellent testing team caught the problems and sent them back to us with useful information on how to find the problems, and so forth. We were already the market leader in our area when I started, and in the 5 years I was with the company we put a couple major competitors out of business. This experience leads me to be highly suspicious of the claims of Agile proponents.

    If someone were to ask me what the secret to success was--because it definitely had nothing to do with Agile principles--I would say two things. 1) They were careful to only hire devs who knew what they were doing, and 2) management went out of their way to keep morale high.

    Nail these two points, and you can be successful regardless of development methodology.



  • @dse said in Is there any big software corporation out there still practicing Waterfall?:

    Huh? I think you are dangerously close to be a manager. Now I know where managers come from.

    What's your objection exactly?

    I've noticed a lot of developers mix-up the terms and use the word "Agile" to actually mean "Scrum" or some other development methodology, so I thought I'd try to nip that in the bud. Scrum and Agile usually come to a company together (like Ruby and Rails), but they're not the same thing. (You can have Rails in PHP, or use Ruby without Rails.)



  • @masonwheeler said in Is there any big software corporation out there still practicing Waterfall?:

    when the code wasn't good, our excellent testing team caught the problems and sent them back to us with useful information on how to find the problems, and so forth.

    Unit tests are supposed to let less of this through to be caught by them. Obvious things should never hit your QA, because that means you failed. They should also be more reliable.

    The fact is, everyone writes bad code. Bad in ways neither they nor other people will notice. Things will break in subtle ways, and not be caught until a year down the line.

    If you spend all your effort trying to keep that from happening, you might waste some time in the short term. But you also won't be relying on dumb luck.



  • @wft said in Is there any big software corporation out there still practicing Waterfall?:

    @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    @wft Pure agile is just as bollocks as pure waterfall. Most companies will be somewhere along the spectrum.

    Well, I'd like to hear from a company being on the side of spectrum where they do it in big phases. Big requirements, big design, big coding, big testing, biiiiiiig maintenance. In that order. Weekly or monthly status meetings and no sprints whatsoever.

    Sounds like how we do things where I work, but I work for state government. On one big project I was on we met every other week but soon stopped after like 4 weeks. I think the project took around 6 months to implement.



  • @masonwheeler said in Is there any big software corporation out there still practicing Waterfall?:

    If someone were to ask me what the secret to success was--because it definitely had nothing to do with Agile principles--I would say two things. 1) They were careful to only hire devs who knew what they were doing, and 2) management went out of their way to keep morale high.

    You missed the #1 most important thing, your scope didn't change arbitrarily. As that is the only way to stay on schedule. Your other points make things run smoothly for sure, but they have little to nothing to do with maintaining a schedule.




  • Impossible Mission - B

    @dragoon said in Is there any big software corporation out there still practicing Waterfall?:

    You missed the #1 most important thing, your scope didn't change arbitrarily. As that is the only way to stay on schedule.

    I'll give you that one. I won't agree it's the One And Only True Factor, but yeah, that did happen and it was important.

    Your other points make things run smoothly for sure, but they have little to nothing to do with maintaining a schedule.

    Sure they do: if you have people who don't care (low morale) or aren't competent, you'll have a heck of a time getting them to produce quality work on schedule.


  • Java Dev

    I recall when we switched to scrum, the PM was happy because he was allowed to give input once every two weeks. And we were happy because he was allowed to give input once every two weeks.

    It did end up working out, though we have been deconstructing it over time as our team slims down.



  • Maybe most corporations have gone back to the rivers and the lakes that they were used to.


  • FoxDev

    @coldandtired said in Is there any big software corporation out there still practicing Waterfall?:

    Maybe most corporations have gone back to the rivers and the lakes that they were used to.

    0_1504178248089_WYDTISI.png



  • @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    Answering questions like those can take weeks and, for maximum reduction of re-work, has to be done before any actual code is written.

    I always do that, and it always turns out I was wrong and need to shift things around after I start coding.

    Maybe things would be better if multiple people participated in the whiteboarding process. I'm usually the only one doing the "architecture" stuff.



    1. True Waterfall rarely exists (as per the definition), there is almost always some capability of a "Change Order" which results in a process that does have feedback loops (which are by definition lacking in Waterfall). Even the originator of the term acknowledged that they did not (commonly) exist.

    2. Agile has many meanings. I like to focus on the difference between "taking into account the Agile Manifesto" [which I prefer] and all of the other ceremony based items that are referred to as "agile". I have yet to find a single project [new or legacy] which can not benefit from the 12 principles and 4 value comparisons of the Manifesto].

    3. If you are going to select "Backlog Driven / Sprint Timebox" ceremonies as your means of achieving the goals of the Manifesto [something I fully support, but differentiate from "being Agile"]...

    3a) "Just breaking it into individual tasks" - is something that is done at the start of a Sprint, not an upfront effort.

    3b) "there's no way you could write a system to do tax-exempt spending account benefits (HSA, TSA, etc) and have something that could be demoed in 2 weeks" - If you know the technology that is going to be used, then a shell [empty] can usually be created in just a few hours, and demonstrated. It could well be months before any end-to-end business domain activities are completed.

    3c) "with that amount of time we fucked it up and had to backtrack a bunch later on." - Umm, that is the point of iterative development. Do the smallest amount to meet the next goal, and then continually refactor to improve.

    3d) "Predictions are worthless for new development, which is all Scrum is about." - NO, in so many ways.

    .....


  • Banned

    @magus personally, I think the main purpose of unit tests isn't to check if the code is correct, but to check if behavior changed unintentionally during implementation of more or less related feature or during refactoring. No amount of manual testing will ever give you that.


  • 🚽 Regular

    @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    1. True Waterfall rarely exists (as per the definition), there is almost always some capability of a "Change Order" which results in a process that does have feedback loops (which are by definition lacking in Waterfall). Even the originator of the term acknowledged that they did not (commonly) exist.

    This is true for ANY project, in and out of software projects. Waterfall resembles other non-software projects that by their very nature need to be rigid. Building construction for example. But even those are going to have complications in the implementation. Perhaps the ground was softer than initial surveys measured and need more piles. Or some material they were originally gong to use was discontinued. Or a new fire code gets passed requires them to change their sprinkler schematics.

    The point is, waterfall is a goal and a mindset, just like agile is. Waterfall's goal is to minimize the risk of too many unforeseen changes to the requirements, but Murphy's Law will always get in the way of that goal. There's no way to 100% accomplish that goal but you can give it a 100% effort to accomplish it regardless.


  • 🚽 Regular

    @gąska said in Is there any big software corporation out there still practicing Waterfall?:

    @magus personally, I think the main purpose of unit tests isn't to check if the code is correct, but to check if behavior changed unintentionally during implementation of more or less related feature or during refactoring. No amount of manual testing will ever give you that.

    Well, yes there are manual regression tests you can do. You'd need a large QA staff to really make it work but it is possible.



  • @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    If you know the technology that is going to be used, then a shell [empty] can usually be created in just a few hours, and demonstrated.

    If it does nothing, there's no demo. You can't demo "just an empty shell".

    @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    3c) "with that amount of time we fucked it up and had to backtrack a bunch later on." - Umm, that is the point of iterative development. Do the smallest amount to meet the next goal, and then continually refactor to improve.

    My exact point was the "smallest amount" was well over two weeks of database design. You can't do that in a 2-week sprint.



  • @the_quiet_one said in Is there any big software corporation out there still practicing Waterfall?:

    @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    1. True Waterfall rarely exists (as per the definition), there is almost always some capability of a "Change Order" which results in a process that does have feedback loops (which are by definition lacking in Waterfall). Even the originator of the term acknowledged that they did not (commonly) exist.

    This is true for ANY project, in and out of software projects. Waterfall resembles other non-software projects that by their very nature need to be rigid. Building construction for example. But even those are going to have complications in the implementation. Perhaps the ground was softer than initial surveys measured and need more piles. Or some material they were originally gong to use was discontinued. Or a new fire code gets passed requires them to change their sprinkler schematics.

    The point is, waterfall is a goal and a mindset, just like agile is. Waterfall's goal is to minimize the risk of too many unforeseen changes to the requirements, but Murphy's Law will always get in the way of that goal. There's no way to 100% accomplish that goal but you can give it a 100% effort to accomplish it regardless.

    Sorry, NO....

    Waterfall (when properly used) means that there is no ability to change. Once the "Requirements Document" is complete [before any architecture, design or implementation begins] it can not be changed. One must deliver exactly what is in the document or FAIL.

    I did actually work on ONE project that was Waterfall in the 1970s. Within a week of the company getting the contract, it was realized that the device would never work. No matter, it was built. It passed the individual tests. When it was turned on [by the client, against written recommendation] it literally caught fire and had a smallish explosion.



  • @blakeyrat

    If it does nothing, there's no demo. You can't demo "just an empty shell".

    Presume Browser based: I can demo <HTML><BODY>TBD</BODY></HTML>
    Similar for any other technology.

    My exact point was the "smallest amount" was well over two weeks of database design. You can't do that in a 2-week sprint.

    Database Design is an EPIC (above feature) and something long term. I can do

    CREATE TABLE Persons (PersonID int)

    in a matter of seconds, and then another table, then refine PErsons to have a reference, then ......



  • @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    Database Design is an EPIC (above feature) and something long term.

    Well derp, but being an "EPIC" doesn't exempt it from the fact that each work item in it has to be less than a week. By the Rules Of Scrum.

    @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    I can do
    CREATE TABLE Persons (PersonID int)
    in a matter of seconds,

    The problem isn't the speed of my typing. Goddamned.

    Of course you can type the words in a few seconds, the hard part is figuring out what goes in it.



  • @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    Well derp, but being an "EPIC" doesn't exempt it from the fact that each work item in it has to be less than a week. By the Rules Of Scrum.

    Wrong. Scrum defines a PBI [Product Backlog Item] which is indeed something the is scoped to start and complete within a single iteration. Aggregations of PBI's is NOT covered by Scrum, but most teams do use Features as multi-sprint aggregations of PBI and then Epics as long term aggregations of Features.

    Of course you can type the words in a few seconds, the hard part is figuring out what goes in it.

    The SQL I gave is a minimum, additional iterations (some within a given PBI, others in many different PBIs) continue to refine it by adding, removing, changing "what goes in it"


  • Java Dev

    @thecpuwizard A table is not a feature, unless you're giving external access to it.



  • @thecpuwizard said in Is there any big software corporation out there still practicing Waterfall?:

    The SQL I gave is a minimum, additional iterations (some within a given PBI, others in many different PBIs) continue to refine it by adding, removing, changing "what goes in it"

    Right; the problem is that takes more time than the time period after which you need to demo it. "None of this shit works, guyz, but look I typed a lot of text in!" isn't a demo.

    Whatever, I think some of those prototype Intel CPUs they sent you when you were blessed by Jesus himself as the universe's greatest (and least humble) programmer might have shot radiation into your brain or something.



  • @pleegwat said in Is there any big software corporation out there still practicing Waterfall?:

    @thecpuwizard A table is not a feature, unless you're giving external access to it.

    100% agreement. But neither is it a PBI... The table can change (even cease to exist, then come back) many times over an extended period of time. The minimal amount of work to achieve an "increment" is small.



  • @blakeyrat said in Is there any big software corporation out there still practicing Waterfall?:

    Right; the problem is that takes more time than the time period after which you need to demo it.

    What are you going to demo is a big part of that.

    Going overly granular can shed some light...

    Demo 1: "I can create a customer" [need a UI "button", a Table with an ID, and an InsertStatement]
    Demo 2: "Customer has a First Name and Last Name" [add two text boxes, change table schema, modify insert statement]
    Demo 3: Customer a Company [one more text box ...]
    Demo 4: "There is a Company Record with ID and Name" [new UI with Button, new Table, new Insert
    Demo 5: "Customer used Company Record" [change Customer UI, change Customer Table, add Relationship, change insert statement]

    Again, these are overly simplistic, but should be sufficient to set the tone for looking at minimimal changes....



  • @thecpuwizard Look, Scrum is great if you're:

    1. Working on an already-finished application
    2. Solving easy problems.

    I ALREADY SAID THAT.

    The problem is: real software development involves solving difficult problems, and Scrum's insistence on the miniminimiminimimal amount of time a task can take is a HUGE obstacle to that and makes it a poor fit.

    The only way to handle that situation is to split your developers working on the hard problem out of the process until they have something Scrum can iterate on. But what's the point then if half your team isn't following the methodology?


  • kills Dumbledore

    @thecpuwizard Doesn't that add a huge amount of work of constantly reworking the schema instead of working out what you'll need up front and putting together a schema in one go with the whole big picture in mind?


Log in to reply