Live data from Hacker News

We've invented waterfall

epicenterconsulting.com

91–100 of 172 posts

Re: We've invented waterfall

#91

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…

This is why corporate software like SAP is so bad. The guy who writes the cheques to the vendor doesn't do timesheets or whatever. His secretary does his expenses and his travel and his holidays. He never touches the software apart from to look at the dashboard and the final generated reports (which will be whizzy). He literally doesn't know it's miserable to use, and unless "subordinates satisfaction with corporate apps" is his bonus metric, literally couldn't give a flying fuck even if he did know.

Re: We've invented waterfall

#92
Am I in the minority who uses both agile and waterfall methods?

The long and the short of it for me is this: There's two ways to solve problems. Agile helps immensely when you are figuring out how the solution would work. When you're solving a problem that might be solved in manual processes largely, Waterfall can help a lot, but not alone.

For unknown solutions, agile gives you a lot of iterative benefits.

For known solutions, waterfall with some agile feedback loops gives you incremental benefits.

What's the difference?

Sometimes, in a business, they have a great process already. It's in paper, or multiple systems, but they have their way of doing things that works. I believe it's called their competitive advantage.

Othertimes, a business is facing a problem for the first time, and wonder "how do we solve this". In this case, doing a big upfront design is a waste of time, starting small and staying flexible is most important.

For me, this mindset of doing both is critical, not one or the other at all times. You simply miss out on too much if you don't use agile, and you run around too much if you ignore waterfall when a solution exists.

Waterfall works where it's a known process, like building a house. You can have agile loops in there when building a house and improve it as you go.

When you're trying to build a new building that's never been built before, an iterative, feedback-centric approach like Agile is a lot more beneficial.

If a company focuses on taking something like Waterfall and introducing feedback loops (agile) like this epicenter thing, is it not a bit clearer than the black-box voodoo out there? Maybe it's just me, but I applaud anyone trying to make software easier. It just shouldn't be a dogmatic, or religious dismissal.

0.02.

Re: We've invented waterfall

#94
post #63
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…

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

You are right, there IS a line between culture and politics.

But thats the thing. You should count politics as part of your requirements too, or thats what the theory states anyway.

For example, lets say you digitized an inventory form for a sales dept of a plastic company. By doing this, you effectively removed use of a pen from the 'system'. Now what politics could you possibly be affecting by eliminating use of a pen? Well, you could cause an uproar between the finance dept and the sales dept. Finance says that the organization's major stock holder is a pen company and the sales department must use pens (for whatever reason...lets pick advertising and promotion).

Now your system made the world efficient but it failed to account the current work practices of your client. You, sir, just screwed up.

Re: We've invented waterfall

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

It feeds into teaching me about people...I'm currently trying figure out how to work with really smart people and how to build and sustain high performance teams.

Yeah yeah yeah...but I did come bearing gifts!

Re: We've invented waterfall

#97
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…

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 by the CIO and other luminaries. People would be shamed for errant configurations, as only the auto-negotiation team could configure NICs.

The director who controlled the auto-negotiate squad was politically powerful, and got all sorts of power out of it -- including banning GigE. As late as 2010, this org was deploying dozens of 100MB NICs to ESX hosts to get sufficient bandwidth. They also purchased 100MB NICs for desktops.

Re: We've invented waterfall

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

Re: We've invented waterfall

#99

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…

Part of why I love my current job is because we focus on the actual users of the software and get feedback from them, not the executives.

It made the initial sales much harder, but the results are much stronger and we've gained such a strong reputation that the software almost sells itself.

Re: We've invented waterfall

#100

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.

Perhaps not. But they're probably running a computer model of the jet (and its systems) under various simulated scenarios. They're also probably building some full-scale mock-ups to test in wind tunnels. And they also have test pilots to fly things which sometimes never make it into wide scale production. So, I'd argue that there is some iteration going on there.

Which is also what the company is claiming to do. I.e. we will create a prototype and walk you through it before we start coding.
Post reply on HN