We've invented waterfall • Hacker News Board

Re: We've invented waterfall

#141

Post by alabut » Sat, Dec 10, 2011, 6:16 AM UTC

jerf wrote: post #130

Stormbringer wrote: post #126

Earlier quoted context omitted.

Agilistas like to pretend that if you're doing waterfall you can't ever go back to the previous step. Whereas in practice, if you find something wrong or confusing with the specification, you just hunt down the business analysts and ask them what drugs they were on when they pooped out the spec. And then after walking them through their mistake, you get a new and better spec. If you do it often enough, they will star…

"Agilistas like to pretend that if you're doing waterfall you can't ever go back to the previous step." The Agilistas are correct. The reason for this is that Waterfall was constructed deliberately as a strawman . The very point of constructing Waterfall was to draw a distinction between the process as it was being presented to the VP, or in this case as it is presented to the customer, and the fact that in practice…

I thought waterfall was a strawman too, until I read The Checklist Manifesto and started learning more about other industries.

For example, large-scale construction projects like skyscrapers are run by gantt charts and committees, which sounds unbelievable and like a disaster waiting to happen. It's like the opposite of every startup I've worked at in the last 4 years. Except it actually works and they keep the everything running smoothly through:

* (at the top level) real time adjustments to huge room-filling charts that shown all the dependencies.

* (at the grunt level in the trenches) an abundant use of checklists to keep work mistake-free and to avoid groups stepping on each other.

* (at all levels) constant and real time communication. Lots of it.

So yeah, I think it's hard to write off waterfall as both ineffective and non-existent if a large industry uses it to such a degree.

Re: We've invented waterfall

#142

Post by wpietri » Sat, Dec 10, 2011, 6:32 AM UTC

alabut wrote: post #141

jerf wrote: post #130

Earlier quoted context omitted.

"Agilistas like to pretend that if you're doing waterfall you can't ever go back to the previous step." The Agilistas are correct. The reason for this is that Waterfall was constructed deliberately as a strawman . The very point of constructing Waterfall was to draw a distinction between the process as it was being presented to the VP, or in this case as it is presented to the customer, and the fact that in practice…

I thought waterfall was a strawman too, until I read The Checklist Manifesto and started learning more about other industries. For example, large-scale construction projects like skyscrapers are run by gantt charts and committees, which sounds unbelievable and like a disaster waiting to happen. It's like the opposite of every startup I've worked at in the last 4 years. Except it actually works and they keep the every…

Large-scale construction projects are also notorious for delays and cost overruns, so I wouldn't make too much of that.

Even granting your point, though, that doesn't tell us much about software. Nobody expects to start a building as a small house and work it up to something the size of the Pentagon. You can't automatically replace every screw in a building in minutes. Buildings aren't made out of words, and they don't have requirements that change continuously. Buildings aren't expected to respond quickly to competitor's new amenities. The construction of buildings is not 100% automatable with modern technology. So I wouldn't be too hasty in suggesting that the Waterfall approach is made more plausible by a similar-sounding process being used in an entirely different industry.

And honestly, real buildings aren't even much like what you're imagining. Stewart Brand's book "How Buildings Learn" examines actual buildings and how they adapt and change in ways very different than what people with GANTT charts think should happen.

Re: We've invented waterfall

#143

Post by buff-a » Sat, Dec 10, 2011, 8:45 AM UTC

alabut wrote: post #129

wpietri wrote: post #122

Earlier quoted context omitted.

I'm totally not getting why you're saying agile approaches are waterfall in disguise. The essential difference to me is in length of feedback loops. Microsoft releases a new OS every few years; some place like Etsy releases new code many times a day. A developer or product manager at Etsy can know within a few hours whether some change is really a good idea; Microsoft not so much. You seem to be saying that because t…

Nope, it has nothing to do with the commonalities in people or roles, sorry I wasn't clear. Let me try again. It's a knock on all rigid processes and dogma, not agile in particular. I trimmed the rant down by taking out the sections that rip into UX firms, with their Big Upfront Design and cocky rockstar designer personas, but it could just as easily been about them. I only cut it because I thought the parallels were…

This is the paper that was the basis of Scrum: The New New Product Development Game, Harvard Business Review, 1986. [1].

The crux of the paper is that you should be "grouping teams by product, not role, and figuring out an interdisciplinary way to work together, rather than running the entire team by the methodology of one specialty".

If the word "Agile" freaks you out, then by all means don't call it that. And certainly there are a lot of bullshit artists plying their trade out there. Indeed, if someone tells me they are "Agile", by default I don't believe them. But as this 1986 paper shows, there is a lot of good data and good theory out there if you but look.

[1] http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%...

Re: We've invented waterfall

#144

Post by JanezStupar » Sat, Dec 10, 2011, 8:57 AM UTC

alabut wrote: post #114

I've got a bone to pick with people that have a bone to pick with waterfall, especially when they don't realize that whatever competing newer workflow they swear by is actually waterfall in disguise. Let's just ignore for a second that a waterfall process sent men to the moon and continues to build skyscrapers, with each project having a set of stakeholders the size of a small city and all while adjusting to a shifti…

I agree with you that any kind of process sucks when a team doesn't really know what they are doing.

And by using a methodology you are saying just that "we have no fucking clue, so we will try it this way that person X sol us".

I have debated agile proponents about whether agile would work in their respective organizations on multiple occasions. Usually I argue it would fail just as much as any other approach?

Why? Because people try to adhere to it strictly and completely miss or ignore their current context, which is usually THE problem they are trying to solve in the first place.

And you are dead wrong about waterfall. Waterfall is not even a methodology. Anyone selling himself as an "methodology expert" while trying to sell you on "waterfall methodology" is a quack and a fraud. Anyone talking about waterfall as a possible methodology is a quack and a fraud who knows nothing about methodologies. Because waterfall is not a methodology, just like adding rat poison to kids candy is not a business model. Waterfall has always, since the very beginning of the term, been an anti pattern a "anti-methodology".

Re: We've invented waterfall

#145

Post by tsotha » Sat, Dec 10, 2011, 10:13 AM UTC

wpietri wrote: post #124

SomeOtherGuy wrote: post #33

Earlier quoted context omitted.

>Most of us would probably agree that their method is worse than more modern methods Not everyone drank the agile koolaid.

Not everyone drank the agile koolaid. Whether or not one drinks the koolaid doesn't matter much. 15 years ago, 1-3 year release cycles were the norm. Now they're uncommon, and becoming less and less so. Some well-regarded shops (e.g., Etsy) now release many times per day. This isn't driven by what process is fashionable; it's happening because of improvements in technology and the way the Internet has shifted everybo…

It really depends on what kind of software you're writing. Sure, startups writing web apps for casual users can have super short release cycles.

But imagine "agile" development for commercial airliner flight control software.

Re: We've invented waterfall

#146

Post by tlipcon » Sat, Dec 10, 2011, 10:14 AM UTC

Duff wrote: post #97

roc wrote: post #49

Earlier quoted context omitted.

Let me tell you why you don't see this happening more often. I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department. Everyone wh…

My favorite thing like this for a purely technical topic was a project where there was a mandatory requirement to NOT support ethernet auto-negotiation. Why? The company had a long-standing policy of manually setting speed and duplex to ensure that there were no duplex mismatches. The was a team of 6-7 people who would audit servers and check switchports, and they produced a report was issued every week, and reviewed…

Several comments here indicate that this practice is outdated. I disagree strongly. Even in 2011 autoneg is flaky on many switches - in a recent shipment of ~100 machines, ~5 of them autonegotiated to 100mbit instead of gigabit. And these are name-brand machines with name-brand switches.

Forcing duplex and speed with ethtool is still relevant.

Re: We've invented waterfall

#147

Post by johnx123-up » Sat, Dec 10, 2011, 10:59 AM UTC

Amadeus2011 wrote: post #98

Some of these comments are missing the point. Their methodology isn't about how to build but on what to build. It's a problem many industries face. When the client is a non-technical person (the norm in making web apps) building the UI first makes good sense.

I agree. Most of the comments are overlooked. I suspect that the OP is competitor to the said company?

Re: We've invented waterfall

#148

Post by johnx123-up » Sat, Dec 10, 2011, 11:05 AM UTC

Ronnie76er wrote: post #28

Waterfall isn't bad in all circumstances. Lockheed Martin isn't iterating a jet into the side of a mountain 100 times until they get it right.

Agreed. Waterfall is usually better when you do client projects. Agile would be better when you do your own product, at the same time Agile may lead to cost overrun.

Re: We've invented waterfall

#149

Post by lhnz » Sat, Dec 10, 2011, 12:04 PM UTC

overgard wrote: post #133

Spearchucker wrote: post #86

Earlier quoted context omitted.

I just love how much sound advice we discard because of our feelings towards someone/something. Ever read Stuart Sutherland's Irrationality?

I agree with the sentiment, but how can you know to trust someone's advice if they're acting in a way that's obviously very socially stupid? (I'm not huge on excessive politeness, but I think it's quite stupid to be aggressive for no reason. What purpose does that serve? Why should I trust the advice of a person that acts that way?)

I assume by treating their argument in a rational non-emotional way...

Re: We've invented waterfall

#150

Post by SideburnsOfDoom » Sat, Dec 10, 2011, 12:11 PM UTC

SomeOtherGuy wrote: post #79

SideburnsOfDoom wrote: post #73

Earlier quoted context omitted.

You have chosen the "just code" brand of koolaid. Results are highly variable, its hard to manage and it doesn't scale. But YMMV.

That response is even sadder. I haven't chosen the "just code" koolaid, but your religious beliefs are so deeply ingrained that you can only perceive me through that lens. As a result, you miss out on the great big world of "every situation is different and you should do what is appropriate instead of what some dipshit hawking books and seminars says".

Actually, both of my previous comments made mention in passing of situations where I though a method wouldn't work. You say "every situation is different and you should do what is appropriate" but make no mention at all of which method is appropriate for which situation.

Books and seminars, we got these, but good agile is done by adding in some open source software tools, a whiteboard, pens and cards, and people with enthusiasm and an open mind. The last one is most important.

If we're still talking about the original post, then absolutely it's a belief system. Not a very well thought through one, though.