int * const p = new int[10];
p[1] = 10;
delete[] p;
if(p[1] == 10)
{
puts(“ten”);
}
else
{
puts(“not ten”);
}

…just because you observe the output to be “ten”…

I and others have repeatedly asked for proof where agile has failed and waterfall or some-other-non-iterative-agile-by-another-name methodology has succeeded.

So far, no one has been able to produce proof.

Even the master-builder Egyptians had to changes some of their plans/design along the way as they built the pyramids.

Please show me where it doesn’t work. Also please show me, in the case where it didn’t work, what did work instead.

I’m pretty confident what what you show me will be some form of agile (NOT necessarily Agile(TM)) — that is, some form of iterative requirements discovery, coding, and testing cycles in short timespans vs. long ones.

I’m still of the belief (and have yet to been proven otherwise), that it is humanly impossible, on any sufficiently large project, to know all the requirements up front with no changes between reqs/specs and testing/release (true bugs/defects notwithstanding).

I defy someone to show me a large project where this is true.

Even in one of the more life-critical situations like the Space Shuttle, they’re making changes to the software and the hardware up to and including the days before launch.

> “just because you’re too lazy to think about a design upfront.”

lol, is that what you think this is about? I’m not saying you shouldn’t give thought to design and lay down some pre-requisite design and basic foundation work. What I’m saying is that a long, drawn-out 3 months requirements and planning/design marathons are guaranteed to fail (where ‘fail’ means that more design and planning will be required somewhere in the project before it gets released).

And if more planning and design is required somewhere before it gets released, then all you have done is shoe-horned bad agile into the middle of waterfall.

so why not plan for change up front, do some design up front (as much as is necessary, but not more) and then start working out the solution.

Newsflash: agile doesn’t always work. Stop trying to pound the entire world into your viewpoint just because you’re too lazy to think about a design upfront.

I am not an experience in large scale projects. But from my experience I know customers are changing their requirement during the project. So I think Agile is the best method most of the commercial application developments.

As Lord Buddha said everything is changing in this world.

Thank you for the comments and links. I had seen that waterfall.html link. It only makes my point even more important: An even worse problem with Waterfall is that there never was Waterfall and everyone is doing a bad practice, wrongly.

It’s possible that their medical/MRI group doesn’t use iterative, but I think it’s reasonable to assume that their military C2 systems are.

http://www.idinews.com/waterfall.html