Did Samsung knowingly and intentionally copy the iPhone? Yes and yes.

as does speling

Exactly, I wasn't going to bring Jobs up, but he was the designer and ultimate decider of what went into a system. Unfortunately, very very few designers can actually do this. But, he still gathered a list of requirements for the teams to develop :)

I'm not sure where you got that one from? Users don't write specifications for software, a designer somewhere does. In fact, you support that with "The rest of the industry has found out that users in general don't know what they want" which is just all the more reason to not let them specific requirements. After all, what you want won't be what someone else wants. Someone needs to do the analysis of what they actually need. That's called requirements gathering. It actually takes significant time and effort in many cases.

I thought it was about successful software projects, not unique interchangeable snowflakes. Perhaps that's where Agile went wrong.

Really? Everything changed? Did HTTP(S) disappear? Did TCP go away? Did HTML vanish? Is javascript no longer used for dynamic web content? Guess what - all of those things are still current today, and still work today. What doesn't are vendor specific items like IE6, and if you were developing specifically for that, well, then you made a terrible choice, especially if it affected your entire application stack.

So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however.

No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central.

What's funny is I was involved in a rather large successful gov IT project. The problem with the failure rate is the same as it is everywhere else - bad management and/or incompetence. Add something like Agile and you can just write it off before you start.

Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model. Take the car analogy, GM is going to design a new car, they're budgeting 'x' for it based on previous history, and 'y' time. This will get it out on date 'z', per the normal car release schedule (once a year) Investors like the new concept, and eagerly await the production run to produce this new wonder. However, for this project, GM departs from their tried and true process, and incorporates Agile. They start work, the teams are too large, scrums eat far too much time so they segment the teams to stay on schedule. As things segment, communication starts to whither, because no one is managing the full project. Stakeholder see the frame, the new engine, etc taking shape per schedule, and decide that a minor change here and there will improve things. It comes time to integrate once the prototypes are designed and built. Gee, those 2 disparate changes now cause the engine not to mount to the frame, and the controls require rewiring because the harness doesn't match up. Now there's a mad scramble, the prototype doesn't make its date, the car isn't built and slips into next year. Stock plunges.

And this is hilarious, because no where do I defend waterfall. What I do attack is the utterly useless Agile crap. Waterfall has it's own set of problems, which we're not discussing here, or at least I'm not. I'm describing the real world, how people try Agile, and how they and Agile fails. You can keep dreaming that it works, but if you have a working "Agile" process, you're not actually practicing Agile, you're doing something far more. And to claim that Agile just incorporates this extra process, well, that's disingenuous, because I can make the same claim that you're following waterfall, just with these minor modifications.

In essence, I practice neither process, but a project management style that is more dynamic that grew out of understanding waterfall's short-comings and agile lately claims some portions of as its own.

It was called project management. :)

Historical revisionism runs rampant in the Agile crowd. Do recall that Agile started with XP programming, more or less, and when that failed (to get traction, produce results, any other measure you care to name) they started slapping additional things on top of it. It has morphed so much over the years that you have to pretty much specify the year and methodology du jour to know whether a project was "Agile" at that time. "Agile" is a failed "methodology", if you can even call something so ambiguous a methodology, and is just code for "we don't like being told what to do or take any responsibility for the results of the project". I'm the polar opposite of that, I take a project and intend to deliver it within specs, on time, and on budget. I generally succeed.

I certainly must not which must be why I was rated troll -5 and you felt the need to respond with a lot of nothing.

Because it sounds good?

You might want to talk to NASA and tell them all their missions have failed.

You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)

I need what I specified. If I need something else now, I should have added on more requirements. In fact, at the start of the project I should have added in an allowance that just maybe I will need to change something, or a dependency in the project may shift in time or not meet its capabilities. BTW, for you Agile people, this is where the Project Manager usually does his work. If they're managing which requirement you're coding and how, he's not doing his job.

If I was originally scheduled to make a simple sort in an adequate time period and then need to add in a complex multi-layered sort, um, yeah? What makes you think changed requirements wind up being deliverable in the same time frame? What vacuum do you live in? Are there pink ponies there too?

Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere.

Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause. I've detailed some of those elsewhere, and the response from the believers is always "Oh, you're doing it wrong" which is hilarious, because in multiple cases they were following exactly what little is laid out by the Agile camp. The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states they are unless you're going LCD. In fact, if you estimate your "velocity" by your worst performing programmer on an Agile team, you may, just may, have a realistic estimate of when you'll supposedly get to the finish line as long as no one throws any new requirements your way. As soon as they do, everything you think you know just went away. Sorry, my next SCRUM is pulling me out of this one...

I'm assuming your next Yaris will come this way?

A company designs and builds a car to safely drive at 70 mph.

You drive at 140mph in the rain, hydroplane and lose control hitting a bridge column, and die. I'd say the fault lies with the driver. What about you?

Said company puts in an ignition switch that's faulty and disconnects the entire control system while driving at 70mph and ignores reports of this problem for a decade. That would not only be the fault of said company, but adds layers of premeditation still to be decided.

You know, if RoR was ever more than a splash in the history of time, maybe someone would have cared more about Rust. Somehow, being "rusty" just doesn't seem to go with hipster, geek, ninja, or rockstar.

You better pass some of that.... C++ compiled with a C compiler after going through a transformation, sure.

This was across multiple companies, just pointing to the fact that many companies fail in this area. I will say I have yet to see 1 successful project that succeeded with large numbers of H1Bs, or any outsourcing project, in many many years.

Sounds more like Microsoft got into the Linux world.