Epicenter is sending out some annoyed tweets while defending the AgileUX movement. They claim their process is nothing like waterfall as it focuses on iterative UX prototyping.
We've invented waterfall
161–170 of 172 posts
Re: We've invented waterfall
#162Did you notice how men in suits are left and right but not in the middle?
My favourite part was how the people appear to hate their jobs. Only in the last panel (Deployment) do you see anyone from the team smiling.
Re: We've invented waterfall
#163Earlier quoted context omitted.
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.
Agile processes don't depend on technology, just people, paper and communication, in fact technology can be a burden sometimes.
Just in case someone from the future misunderstands this: I don't mean that agile drops analysis, documentation, planning or monitoring (they are essential to it) but it leaves the "intensive" and "before" parts out.
Re: We've invented waterfall
#164Earlier quoted context omitted.
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/c…
I have read the paper multiple times over the years.
The quote "is risky and invites failure" is correct. However, another quote, even on the very same page:
"However, I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks."
These suggestions are to 1) Add an additional (preliminary) design phase, after requirement analysis. 2) Much greater documentation. 3) Perform the entire sequential process twice (not x amount of iterations, just two times). 4) Additional activities and documentation during testing phase. 5) Involving the customer.
His diagrams require close scrutiny, as on first inspection it seems the process is markedly different, when it is really not. It is still an entirely sequential waterfall process, just with an extra phase (preliminary design).
Re: We've invented waterfall
#165Earlier quoted context omitted.
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.
Development processes very similar to todays "agile" family, existed back in 1970. "Evolutionary prototyping" for example (a member of the "prototyping" process-family), is one of the precursors for todays agile practices.
Re: We've invented waterfall
#166Earlier quoted context omitted.
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?
like the parent or evergreen? No I have never worked anywhere that promoted such abject waste through "adherence to policy" but I likely would not have chosen to work at such a place to begin with.
Re: We've invented waterfall
#167Earlier quoted context omitted.
"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…
I thought waterfall was a strawman too, until I read The Checklist Manifesto and started learning more about other industries. For example, large-scale construction projects like skyscrapers are run by gantt charts and committees, which sounds unbelievable and like a disaster waiting to happen. It's like the opposite of every startup I've worked at in the last 4 years. Except it actually works and they keep the every…
Waterfall has no such history in the software domain. Analogizing software to construction has a long and worthless history, and it has failed to produce one actionable insight that I'm aware of. (It has produced some really dangerous pronouncements about how software engineering should be done, of the kind that you can crash and wreck a company on, though, so there's that.)
The problem is that construction has a completely, radically different cost model than software. If they could possible throw up one building today, tweak it, and throw up another tomorrow, they'd go iterative too. Instead, they have horrifying implementation costs that have no analogy to software; if Waterfall "works" for them it is only because they have no other choices. That's hardly a ringing endorsement, as wpietri observes.
Re: We've invented waterfall
#168Earlier 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…
Several comments here indicate that this practice is outdated. I disagree strongly. Even in 2011 autoneg is flaky on many switches - in a recent shipment of ~100 machines, ~5 of them autonegotiated to 100mbit instead of gigabit. And these are name-brand machines with name-brand switches. Forcing duplex and speed with ethtool is still relevant.
It sounds like you have either crap NICs or crap cables.
Re: We've invented waterfall
#169Earlier 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.
And horseless carriages used to be less reliable than horses. The problem is the longstanding nature of the policy. They were paying a team of 6+ techs, surely they could afford a process-review/technical updating meeting once a year? And surely there's a better way, such as standardizing on a brand of NICs and of switches, and being done with it. If you can't push an update to the machines to prevent this anyways.
Besides, it shouldn't cause cascading failure so the worst case scenario is a tech call, the same as for an unplugged cable.
Re: We've invented waterfall
#170Earlier quoted context omitted.
You have a choice of koolaid. The waterfall brand is implicit in the statement "We don't write a line of code until we know your business as well as the people who keep it running every day." - it is founded on the assumption that you can finish requirements for the entire system before starting to deliver working software, and no feedback or iteration is needed. My experience is that for the majority of software pro…
> this was well known 10 years ago. This was well known 40 years ago: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ign…
Very true, and I should have picked an earlier date. But I was erring on the side of caution, and it somewhere between 1990 and 2000 when agile methods, which explicitly reject big upfront design, became mainstream.