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

111–120 of 172 posts

Re: We've invented waterfall

#111

Post by [deleted] »

jakejake wrote: post #71
namank wrote: post #62

Earlier quoted context omitted.

There is process called Contextual Design. Part of it talks about treating the tacit knowledge of a workplace like a very necessary requirement for your software. So that means including the culture of the workplace in your reqs. It sounds dumb at first but it makes perfect sense. What you did at that place was to apply a bandaid to a fracture where it really should have been a cast. But you didn't know it was a frac…

Interesting point until the twatty comment at the end.

[deleted]

Re: We've invented waterfall

#112

Post by recusancy »

roc wrote: post #49
giberson wrote: post #41

Here's what I would like to see from a consulting company for once. Don't interview the stake holders of the company, they don't use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you're getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn't re…

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…

This needs to be a post in itself!

Re: We've invented waterfall

#113

Post by Duff »

rhizome wrote: post #101
Duff wrote: post #97

Earlier quoted context omitted.

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…

I don't know if you were around 10 years ago, but there used to be real problems between certain network cards and switches that prevented autoneg from being 100% reliable. For any company of a certain age I would not be surprised to see a policy like the one you describe.

Absolutely... IIRC, the IEEE standard was ambiguous, and each vendor implemented things differently. I think the standard was "fixed" in 1999... This situation happened in 2009!

But the technical problem wasn't the problem -- the issue was that they created an inquisition that had outlived its purpose.

Re: We've invented waterfall

#114

Post by alabut »

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 shifting landscape of nearly infinite variables. Especially the first few moon missions, when no one had done it before. It's why all of the original astronauts were test pilots - not just because of their bravado but also their experience in co-designing unfinished machines along with the engineers to bring it to a workable finished state. The roots of the modern HCI and human factors industries comes from analyzing and optimizing the usability of cockpits. The astronauts even had their own usability jokes about a model of training jet that was so user-unfriendly that the emergency instructions for ejection were printed on the side of the canopy, which is nuts because step one was to blow the canopy (along with the rest of the instructions) up off into the sky.

These weren't dumb monkeys strapped to a giant tin can and blown into space, and neither were the engineers that sent them there. With waterfall.

So you use agile/xp/scrum/whatever and swear software is way different than building bridges. I've worked on and with several of those teams, with varying levels of strictness, and guess what? It's still basically waterfall. But instead of PMs owning the process and spec'ing things out in advance, engineers own the process and the spec is written and re-written during development on a bunch of index cards with sharpies like a grade school art project (or the digital equivalent), designers get barely a week ahead of each sprint or run around like caffeinated janitors cleaning up after each sprint, and documentation gets written last or not at all.

And before anyone does ad hominem attacks on whether my teams were doing agile correctly, this is the same dynamic I witnessed at the most famous agile and rails development shop you can think of. You probably only need one guess to figure out who it is.

What matters then, if it's not process? It's called expertise - a broad collection of various techniques and the context-specific awareness of when to use each one. Instead of blindly following a process and trying to hammer it into every situation, take a tools-instead-of-rules approach to using whatever techniques are appropriate for each project.

For anyone interested in this kind of flexible thinking instead of linear GTD productivity tools that leave you stuck in robot mode, there's an excellent book called Pragmatic Thinking And Learning that goes into a lot more detail and pulls inspiration from how the nursing industry overhauled their education system in the 70's.

http://pragprog.com/book/ahptl/pragmatic-thinking-and-learni...

I know, from the book publisher that sells the pickaxe Rails book and stuff on agile. Oh the irony!

Re: We've invented waterfall

#115

Post by peteforde »

My founding business partner Ryan McMinn spoke at an open source conference in Toronto a few years ago. In the talk he explained how and why we built Unspace the way that we did.

http://www.youtube.com/watch?v=lIQIZ0NIkxk

He talks extensively about the need to work directly with the end users of the system, instead of the management. The realization that specifications are usually nothing more than mutually assured destruction.

Pretty much the only thing that's changed in five years is that the scale of our company has grown, and now we do indeed have contracts with our clients to protect us from bad things.

Anyhow, I highly recommend the video if you're looking for an in-the-trenches perspective.

Re: We've invented waterfall

#116

Post by rhizome »

quanticle wrote: post #109
rhizome wrote: post #101

Earlier quoted context omitted.

I don't know if you were around 10 years ago, but there used to be real problems between certain network cards and switches that prevented autoneg from being 100% reliable. For any company of a certain age I would not be surprised to see a policy like the one you describe.

The surprising thing isn't the policy. The surprising thing is the persistence of the policy even after it's no longer beneficial in any way. It's been more than a decade since Ethernet auto-negotiation became reliable. During that decade, that company has paid for a team to go around and do manually what could have been done by an automated process for a trillionth of the cost. That's a staggering amount of waste.

The policy has to be proven to no longer be beneficial, and I'm pretty sure every major OS has had a way to remotely set the card to a fixed configuration or autoneg since around then, but that's a separate issue.

Re: We've invented waterfall

#117

Post by ansgri »

twerth wrote: post #56
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…

Well said, and the exact reason I moved away from consulting after a decade of doing it. The developers often get blamed for "not understanding how real people use the system". Most features are requested by C level people who have never actually used the system. While consulting, I've actually been told NOT to talk to the users who will be using the system. In a large enterprise it is often about power and politics,…

For a small consulting company?

Re: We've invented waterfall

#118

Post by zedshaw »

jameskilton wrote: post #67
zedshaw wrote: post #64

Actually, this is refreshingly honest compared to the "agile" methodologies. Having worked with plenty of supposedly agile consultants I can tell you they basically do waterfall it's just their cascading stupidity starts with code and then wanders around writing unit tests until the client is tapped out. At least this is doing some actual user interface design and usability testing. Then again, I doubt these guys do…

Really? Claiming to have invented the most well know and also the worst software development process is honest? It's a bold-faced lie written only to get clients. One can only imagine what actually happens in communication once they have a client. If the marketing is a complete lie, then I can't imagine the company itself can be trusted.

>Claiming to have invented the most well know and also the worst software development process is honest?

They claim to have developed the best process, just like all the agile con artists out there.

Re: We've invented waterfall

#119

Post by zedshaw »

sleight42 wrote: post #106
zedshaw wrote: post #64

Actually, this is refreshingly honest compared to the "agile" methodologies. Having worked with plenty of supposedly agile consultants I can tell you they basically do waterfall it's just their cascading stupidity starts with code and then wanders around writing unit tests until the client is tapped out. At least this is doing some actual user interface design and usability testing. Then again, I doubt these guys do…

Most "agile" consultants you know start coding from day one? If so, I now understand much better why you dump so much on agile. I had myself a nice little nerd slap fight on twitter earlier today about this post. "Agile" without up front planning and research is just dangerous.

Oh, now we're going to get into the perpetual argument of what is really agile? Agile's like porn. Everybody who does it claims they know what it is, but nobody can define it. Instead they call "successful" projects properly agile and failures are just shoved under the rug with claims they didn't do agile hard enough.

So please, save your criticism that you know what is and clearly I don't. You can't define it, and if you think you can I know you don't follow it.

Re: We've invented waterfall

#120

Post by sleight42 »

zedshaw wrote: post #119
sleight42 wrote: post #106

Earlier quoted context omitted.

Most "agile" consultants you know start coding from day one? If so, I now understand much better why you dump so much on agile. I had myself a nice little nerd slap fight on twitter earlier today about this post. "Agile" without up front planning and research is just dangerous.

Oh, now we're going to get into the perpetual argument of what is really agile? Agile's like porn. Everybody who does it claims they know what it is, but nobody can define it. Instead they call "successful" projects properly agile and failures are just shoved under the rug with claims they didn't do agile hard enough. So please, save your criticism that you know what is and clearly I don't. You can't define it, and i…

God damn, Zed. You sure jump to conclusions that people are going to fight with you! Not that you remember it we've met twice and had perfectly normal conversations.

No, I agree, dammit! So take that!

Although I can see where you may have misread my honest question as rhetoric to indicate conflict. That was, as I said, an honest question--though perhaps missing a few words. I was inquiring whether the "agile" consultants you've known start coding on a new project from day one of the project indicating that, in those cases, they aren't taking much time at allfor research or planning.

Agile is a broad label that doesn't make a lot of sense. I've been in the biz 16 years. If there's anything that I preach it's "it depends" and "YMMV". Please don't assume we're all out to get you or that we all believe that we know better than everyone else.

Post reply on HN