Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We've invented waterfall

epicenterconsulting.com

Post reply on HN
Print view View original

121–130 of 172 posts

Re: We've invented waterfall

#121

Post by potatohead00 »

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…

Interesting outlook on things... I've always thought (and argued when possible) that the key to any software/computer issue is smart people - not 'rockstars' and these developers who think they're the center of the universe, but a team of capable people, familiar with a broad range of technology and capable of solving problems, using whatever tools are needed. But I have long thought that waterfall just couldn't work - but I suppose it could if you have management and executives that understand the 'product' at the end will be iterated.

I have also been meaning to pick up that book...

Re: We've invented waterfall

#122

Post by wpietri »

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'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 there are the same sorts of people involved, and because one has a giant spec document while another has a stack of index cards that might be called a spec, then they're the same. Which isn't making any sense to me.

Re: We've invented waterfall

#123

Post by winterwaterfall »

MattRogish wrote: post #74

If you read the book's PDF ( http://epicenterconsulting.com/book_source/Obsessively-Thoro... ) you'll also note that: "Hal was the first to introduce the concept of building an interactive demo as a key part of the software development process" Really? I can't imagine that's true

Check out Hal's website with JavaScript disabled:

http://www.halhelms.com/

What's going on there? Hal Helms home helplessly hacked? Or just poor page design?

Re: We've invented waterfall

#124

Post by wpietri »

SomeOtherGuy wrote: post #33
pingswept wrote: post #26

Earlier quoted context omitted.

Most of us would probably agree that their method is worse than more modern methods, but spending time making fun of them is like making fun of someone for driving an old car. You could be working on your startup right now .

>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 everybody's expectations.

Whether you're officially using some Agile(tm) method or not, you'll have a lot in common with those folks if you meet user demand for faster delivery. There are some niches that are lagging on this trend, but my pals in those areas still feel the pressure. They'll still be able to be waterfall-ish for a while longer, but I doubt it will be forever.

Re: We've invented waterfall

#125

Post by raymondcamden »

willurd wrote: post #83
rickmb wrote: post #68

Earlier quoted context omitted.

We you say "he cares" I presume you mean "cares about slick marketing to clueless clients". Because Epicenter obviously doesn't give a damn about either the truth or software engineering. I'm sorry, but the people who claim the one true method is keeping the programmers locked in the basement without real world input or feedback are the bloodsuckers.

No, I mean that he cares about giving his clients a great product. He's not just in it to soak money out of people; he actually cares about the outcome, much like an artist cares about their paintings. And look, I'm not Clark. I don't speak for Clark. This is just the experience I had working with him and getting to know him for a year and a half.

I can ditto this. I've known Clark for years. He is an honorable person, as is his coworker Ben Nadel. Fault them if you will for 'inventing' something that already existed, but this was - at worst - an innocent mistake. How many people here have reached out to them to try to help correct their mistake?

Re: We've invented waterfall

#126

Post by Stormbringer »

wpietri wrote: post #122
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'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…

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 start to catch on and actually do their job better. Don't think of that as a poke at BA's either, everybody puts more effort in if they know that someone gives a crap about what they do. They may not like it at first, but you're actually empowering them.

Re: We've invented waterfall

#127

Post by Stormbringer »

potatohead00 wrote: post #121
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…

Interesting outlook on things... I've always thought (and argued when possible) that the key to any software/computer issue is smart people - not 'rockstars' and these developers who think they're the center of the universe, but a team of capable people, familiar with a broad range of technology and capable of solving problems , using whatever tools are needed. But I have long thought that waterfall just couldn't wor…

Back when the competing methodologies were waterfall and RAD they used to say that 50% of all software projects failed.

When Agile became super popular they started saying that 70% of all software projects failed.

Hmmm....

Re: We've invented waterfall

#129

Post by alabut »

wpietri wrote: post #122
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'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 obvious with the diagram on the Epic Consulting website.

What I'm saying is that if waterfall means people are grouped together by specialty - programmers with programmers, designers with designers - each group is run by one dominant process suited to only one of the specializations, and each group tends to work in different stages, then both traditional UX design and agile development are run as de facto waterfall teams, whether by explicit hierarchies or simple stakeholder buy-in.

Consider this - what's the difference between:

1) a PM spec'ing things out in advance and basically telling everybody what to do and in which order.

2) an agile shop coding things up on the fly and telling the designers to run after them to clean up the visuals without making major changes, so they might as well be building to a spec.

3) a UX firm mapping out how the product works before handing off to peon engineers that can't make major changes and might as well be building to a spec.

To end on a positive note, there is one other solution to expertise, by the way. It's 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. That way you're picking good ideas from across different processes and adapting to the company culture to boot. For example, TypeKit does daily stand ups at 10:05am every day and that's an aspect of agile that they've liked enough to use for the whole company, but I'd be surprised if their designers were checking their art assets into Pivotal Tracker or the programmers were writing up UX journey maps of each user persona.

Steve Jobs always liked to describe Apple as the biggest startup he knew and a more accurate description would be that it's a collection of startups, with each one focused on a single product. Seems to work pretty well for them.

EDIT: fixed a few formatting errors.

Re: We've invented waterfall

#130

Post by jerf »

Stormbringer wrote: post #126
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…

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 it doesn't work at all and therefore it could not have been what actually happened. Therefore, given that it isn't a possible process anyhow, we should embrace an iterative approach, because ultimately there's no alternative. We should face up to the truth and thereby learn to take proper advantage of it, instead of sneaking it in the back door, hiding it in shame, and deliberately doing stupid things that can't work because management thinks it makes them happy. And in this case, there's no possible way that that is an accurate description of what happens in any significant project that company undertakes.

If you don't understand that Waterfall is not and never was a "real" methodology and don't grasp the history, which it seems still almost nobody does, then you don't really get what's going on. And attempting to rehabilitate Waterfall into a real or viable methodology is metacontrarianism [1] run amok. There's no point in performing CPR on a scarecrow.

[1]: http://lesswrong.com/lw/2pv/intellectual_hipsters_and_metaco...

Post reply on HN