Live data from Hacker News

We've invented waterfall

epicenterconsulting.com

81–90 of 172 posts

Re: We've invented waterfall

#81
post #66
post #55

Earlier quoted context omitted.

Waterfall is actually considered the very best model for software development, when the requirements are known up front in excruciating detail. An average project experience around 25% change in requirements. Hence waterfall is highly unsuited for the majority of projects, since it does not handle requirement changes well. However, in a few areas such as aeroplane control software, space shuttle software and similar,…

"waterfall" was a made up term invented in a paper to describe a hypothetical development process, not an actual process.

The term "waterfall" wasn't coined by Royce in his paper. His paper was a set of suggestions to improve what later became generally known as the waterfall process.

Re: We've invented waterfall

#82
post #49

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…

>> It's simply too easy and financially rewarding to allow a client's political nonsense to screw up every stage of a project. I have less stress, the people who pay me are happier and I bill far more hours.

This is now one of my favorite comments from this site. Very well put!

Re: We've invented waterfall

#83
post #68
post #57

I actually know Clark Valberg, the founder of Epicenter Consulting, and did some work with him a few years back; he's a great guy. You guys can criticize him all you want, but he actually cares. We should direct our efforts towards the bloodsuckers, not the people giving blood.

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.

Re: We've invented waterfall

#84
post #49

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…

Great anecdote that illustrates this principle observed by Upton Sinclair:

"It is difficult to get a man to understand something when his salary depends on his not understanding it." (from I, Candidate for Governor: And How I Got Licked)

Re: We've invented waterfall

#85
Ok, I just invented a new methodology, I dub thee: "Agilefall"

First we meet and discuss the goals for the sprint. Then I design (usually some class diagrams on a sheet of paper or board), then I code and test it (unit tests of course) and finally check it in. Each 4 to 6 week sprint is internally structured as a waterfall. :)

Re: We've invented waterfall

#86
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.

I just love how much sound advice we discard because of our feelings towards someone/something.

Ever read Stuart Sutherland's Irrationality?

Re: We've invented waterfall

#87
post #81
post #66

Earlier quoted context omitted.

"waterfall" was a made up term invented in a paper to describe a hypothetical development process, not an actual process.

The term "waterfall" wasn't coined by Royce in his paper. His paper was a set of suggestions to improve what later became generally known as the waterfall process.

And Royce was ultimately advocating an iterative method (rather than a strict waterfall), not unlike most agile methods today, although his cycles were much larger.

If one is interested in software development methodology, I strongly recommend taking 15 minutes to read the actual "waterfall" paper[1].

Poor guy, Winston Royce is one of the most misunderstood folks in the industry.

(By the way, curiously enough, Royce's son William was a major contributor to the Rational Unified Process.)

[1] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

Re: We've invented waterfall

#88

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…

You're exactly right – but you realize, there's a whole group of people -- a whole discipline, in fact, that does exactly what you're talking about, right?

We're designers.

And we do have & run consultancies. Places like IDEO, Frog Design, Adaptive Path, RED, Doblin (Part of the Monitor group now), Gravity Tank, Teague -- and many, many more.

User centered design processes should be backed up by rich user stories, that come from real user experiences. The only way to do that is to go out in the field and get exposure to the who, what, when, why and how of what the users are doing, want to do/need to do and how they use your product/service.

And if you do it right, you can make a much more successful product that sells a lot better while actually doing some good for the users.

Not a bad line of work, IMHO.

Re: We've invented waterfall

#89
post #15
post #12

Meh. This is hardly the most ridiculous thing I have seen on the internet. I am sure this methodology will work sometimes for some clients. Heck, I bet a lot of startups here on HackerNews are using similar methodologies - but without the early usability testing. If nothing else, at least this company are differentiating themselves. Haven't seen a lot of other consultancies get posted up here on HackerNews. Every pro…

This was posted on HN so that we can make fun of it, and I think we're right to do so. You can be as wishy washy as you like about different situations requiring different processes, but have you ever seen somebody successfully isolate software engineering from coding and put them in sequence?

I actually once worked for a place that didn't have this exact process, but they had a heavy process I'm sure nobody would describe as agile. And it worked pretty darn well.

They designed educational games for early elementary education. Every game activity was hashed out with a working committee consisting of an educator, a technical writer, an artist, and a programmer. They'd take a few hours and talk about the concept that the kid playing the game was supposed to learn (say, measures of weight), then they'd brainstorm ideas for potentially entertaining scenarios in which the concept could be explored (say, a flea circus), then they'd start to storyboard various activities and interactions.

Then the tech writer would produce notes, people would review them, and 2-3 weeks later, they'd do it again, refining concepts and interactions.

This process would stretch out over months, and by the time it was finished, the tech writer's notes essentially comprised a complete state machine for the activity described in English on paper. And the artists/media people had the assets for you in the right media formats. Usually sensibly named. Programming was generally pretty straightforward.

You know how a lot of the time that non-technical "idea guys" seem to have this terrible attitude? "Hey, I've already done the hard work of coming up with the idea, all you need to do is translate it into code."

This was one of those rare situations where it was often more or less true. But it was because the people coming up with the concepts were really part of a creative and disciplined process where they had to come to grips with the details in a way that usually only programmers have to.

Oh, and after things were done with programming, they had a QA team compare it against the spec and an educator's review.

They produced a pretty good product. Sometimes I think it's a shame I didn't stay longer.

Post reply on HN