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

151–160 of 172 posts

Re: We've invented waterfall

#151

Post by SideburnsOfDoom »

tsotha wrote: post #145
wpietri wrote: post #124

Earlier quoted context omitted.

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.

I can. I'm seeing automated tests. A whole lot of automated tests. Unit tests, performance tests, integration tests, executable specifications, tests with real hardware.

I can be done; you have to optimize for what's important to the project at hand.

Re: We've invented waterfall

#152

Post by buff-a »

In an ideal world, Waterfall will lead to a worse product than an iterative one. We don't live in the real world, and I expect these guys deal with clients who regularly fall into the -from-hell[1] category. I would bet that many people posting here aren't running consultancies and don't have experience with such clients (or any clients).

In such a situation, it is in fact entirely rational to develop a lightweight, low cost UI that a non-technical person can commit to, i.e. sign a contract. The developer can then go off and implement it with a very clear legal case if the client then chooses not to pay because "its not what we wanted".

Its not what I do, and I know that many here take a more involved approach to their clients, but its undeniable that it is a successful business model, and in some cases I believe it can produce some result where otherwise there might be none. Equally I'm sure it produces results that are ultimately not used, but where the company still gets paid.

[1] http://clientsfromhell.net/

Re: We've invented waterfall

#154

Post by roc »

ScottBurson wrote: post #139
roc wrote: post #63

Earlier quoted context omitted.

Personally, I see a very clear line between culture and politics. The people of the various departments didn't have any conflicts. It was strictly between department-heads. And, for what it's worth, the C-level types loved the project too. What I did was replace a wooden peg with a modern prosthetic and upset the guy who was selling wood oil for conditioning the peg and the guy who sold the leather straps [1]. edit:…

Seems to me the C-level execs should have given you more cover. It's their job to manage their organization, not yours. This strikes me as a failure of leadership on their part.

Sure. But have you ever found a large company that paid any of their bills on time? Particularly after they have the deliverable, their incentive is very much to allow their middle managers to continue inventing 'concerns' and delay payment.

Everything was couched in "We're really happy. We're not sure why Bob isn't. But we'd really like you work with him to sort that out."

Re: We've invented waterfall

#155

Post by jt2190 »

ricardobeat wrote: post #138
rodw wrote: post #87

Earlier quoted context omitted.

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'…

He wasn't advocating iterative methods in the agile sense, in fact he calls for "complete program design" before any analisys or coding, along with intensive documentation, planning, controlling and monitoring. An iterative approach to development drops nearly all of those. The graphic where he shows cycles going back stages is used to exemplify failure, which he proposes to fix via the strict practices above.

Or, he could be advocating the most agile process that the technology of the time (1970) would allow. Remember that there were no desktop computers, no internet, the programming language C was just being created.

Re: We've invented waterfall

#156

Post by PakG1 »

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…

For these political reasons, it's important to have executive-level support, or else it would never fly. My first job out of school was doing exactly as the gp suggests at a national telecom. Job-shadowing people in their day-to-day work, understanding their problems, and turning around web/desktop apps within days or weeks to solve their problems. We had huge success. We won an international award for what it's worth (Stevie Awards for Best Support Team). We saved our company millions, and were one of the keys for the company to survive a big labour dispute. Can you believe that previously, for a national telecom, all orders for corporate telecom solutions had to be gateway-checked by a single person? We democratized stuff like that so that processes could be much more flat. No need for requirements documents, no change control, complete freedom of creativity, complete freedom to decide what work to accept, etc. I know how that's sometimes necessary for big projects, but for small high-ROI stuff, it was beautiful.

The other side of the story is that we ran into huge political problems. Every day, someone was trying to kill our team because we were making the traditional IT groups look bad with our turnaround time and solutions that worked. On the other side, we were automating things that people didn't want automated. If we didn't have support from the CEO down through a specific chain of command, we would have been killed within months, if not weeks. We didn't even call ourselves developers. Our official position title was business analyst because then IT would bug us less. We weren't even part of the official IT department because those guys couldn't get outside the box. So we were just a small group of business analysts who tried to hide until we were too successful to hide anymore. That's when the attacks really started coming. And then we continued to be successful, and then they started trying to copy us instead. Last I heard, that team's unfortunately been swallowed up by the bureaucracy now, and is a shadow of what it once was.

Fascinating experience.

edit: added end of the story

Re: We've invented waterfall

#157

Post by eli »

MortenK wrote: post #78
jameskilton wrote: post #69

Earlier quoted context omitted.

"Waterfall" was defined in a paper describing how NOT to do software development. The problem was that very few people at the time had any process at all with software so seeing this they gave it a try.

The paper you and "gujk" are referring to, I believe must be Winston Royce's paper. It's wrong to say that the paper is a description of how not to do software development. Rather, it's suggestions for a set of improvements to the process, while retaining the sequential nature. In the paper, Royce considers waterfall to be a good process, but with flaws which result in high risks. These flaws is what he addresses in…

He said, and I'm quoting, that the pure waterfall method is a good concept "but is risky and invites failure." He described how it leads to massive cost and schedule overruns. It was definitely a process that he did not think you should use.

His proposed solutions that you call "modified waterfall" are modified quite a bit. (As an aside, he never used the word "waterfall.")

The paper is here: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

Re: We've invented waterfall

#158

Post by wpietri »

tsotha wrote: post #145
wpietri wrote: post #124

Earlier quoted context omitted.

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.

People have been doing it with medical devices, so I don't think it's impossible. I agree it would have to be done differently, but then avionics waterfall has to be done differently than order-entry systems waterfall, so that's nothing new.

Re: We've invented waterfall

#159

Post by blueprint »

bernardes wrote: post #24

"Unlike a traditional development process, ours establishes all the system's requirements before a line of code is written." This is freakin' unbelievable. ROFL

Might explain why the "Code" part of their process seems so lacking in substantial details!

Re: We've invented waterfall

#160

Post by rhizome »

WettowelReactor wrote: post #135
rhizome wrote: post #116

Earlier quoted context omitted.

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.

Thats why policies, like contracts, should never be evergreen. Policies simply amount to internal contracts and any company that does not regularly review and refresh them is doomed to this kind of waste.

Have you ever worked at a company big enough to have IT policies like this?
Post reply on HN