" Characterizing them as pushing the "omg Terminator" line is just lowering the level of discourse here. That is clearly NOT what they are doing."

Are you sure?

"they are pointing out, rightfully so, that any entity much more intelligent than us, and with a goal set alien to us (like maximization of the number of paperclips in its collection) might as well be out to exterminate humanity"

'AI' means "Artificial Intelligence". The "Artificial" part means it's built by us, human beings, so there it goes the "alien goal". But, oh, you could tell that this AI, being selfconcious and autoevolutive, can develop its own goals... Tell me how that is *not* "omg Terminator" when we are today as far from artificial selfconciousness as we were back in Eliza's day.

And then, the "Intelligence" part means, well, it's not clear what it means but, in the end, it surely doesn't necessarily mean "MORE intelligent THAN US". And even then, one thing is planning for something, quite a different one achieving the intended goal. You see, we are to be considered more intelligent than cockroaches or mosquitoes and we certainly have gone the path of exterminating them (that it would be such a good idea is a different issue), but they are still there.

"because it will do so through simple outcompetition"

Yes, the Secret Council Of Mosquitoes And Cockroaches' fearmongering members also used that argument. But, letting aside the SCOMAC, it is not enough to have the intelligence to, and the goal of, eradicating humankind (both quite unplausible things as of now), you also need a viable interface to the real world, you know, these Terminators were real things, not just ones and zeroes, and that's why they can go overthere killing people.

In the end, we don't need to resort to an AI that it is as of now lightyears of being possible when we have true and tested nuclear arsenals that could achieve the same goal in a very humanly way.

So, yes, everything basically goes down to "omg Terminator".

"Why do you assume that the comments against AI must come from the same person?"

Because I'm a HI. Being good at assumptions is a quite successful evolutionary trait in our species.

I'm, of course, not saying that all AC comments come from the very same person but that an obvious subset of them do.

"Not to mention the fact that he is funding MIRI. If you were giving millions of dollars to a research institute devoted to mitigating existential risk from AI, you would probably become pretty knowledgeable on the subject too."

Or you just demonstrated yourself to be gullible enough to give your money to a certain kind of snake-oil sellers after watching Terminator one time too many.

Remember that being outstanding in some fields doesn't preclude you to be stupid in others (specially when your previous success makes you think about yourself like some kind of infallible demi-god).

"This, of course, means we can use them in the same way you use a canary in a coal mine. If they all mysteriously end up dead at or around the same time, we know to be on the lookout for a murderous rogue AI bent on eliminating dissent."

Quite rite.

And, just for the record, I for one welcome our superior AI overlords.

"You know, if AI research suddenly gets heavily regulated or even banned, their jobs might fly away."

You know, if their jobs weren't heavily regulated they'd soon discover you (the repetitive Anonymous Coward going with the same boring arguments again and again in these comments) are nothing more than a trolling AI, and a lame attempt at it, and would return you to the dirty pits you belong.

"IBM's PC strategy from the mid '80s to mid '90s could be summed up as using their influence to prevent networking, multi-tasking and file permissions from happening on the same platform at the same time."

Of course yes.

That explains why in the mid '80s to mid 90's IBM was busy in a joint venture with Microsoft first and alone afterwards... to produce a PC system with networking, multi-tasking and file permissions and even 32 bits (OS/2).

Or maybe you are wrong.

"An ELE shows up about every 60 million years. If it kills 6 billion people, then that is on average 100 people per year, which is small, but still much larger than they imply."

It would directly kill those 6 billion but then, it would stop humanity from growing at least 25x that number (provided it takes 25 generations to rise back to 6 billions and that 6 billions is more or less the max capacity of the Earth). This would mean -as per your numbers, about 2500 people/year, and that is without taking into account the life standars for the survivors or if it doesn't manage to extinguish the species altogether.

"It's good to have a healthy fear of asterisks -- there's a big difference between "rm -rf *.tmp" and "rm -rf * .tmp"

But surely the space is the villain there."

No, no... it is the asterisk coming from the spaces.

Yes.

Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.

Agile, being about "Individuals and interactions over processes and tools" is specially good at that.
The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.

"Because it sounds good?"

No. Because it is about individuals, not unfaced meatballs.

"By definition, if can't fit into a single Sprint, then you cannot do it"

That's right.

But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.

Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.

"The report is required to be done by Dec 1"

That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.

This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.

"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."

You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold:
1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be.
2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.

"Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally."

Agree on that. At the very least, a developer-opened task would have to be agreed first with the customer or even created by the customer himself upon the developer's request.

"I came back 6 months later once only to find out..."

Your fail. If you had come back two weeks later instead of 6 months, you would have found much earlier. You know, "agile" is a burden for the customer as much as for the developer. You can't have "agile" without both of them.

"the bugtracker agile system."

You yourself say it afterwards: just call it "the issue tracker system" and you are done.

And, yes, it probably would work better than the average "agile in the forms, old school everywhere else" because, since most of the problems about agile come from people and culture clashes than anything else, having a simple and easily understandable means to produce a queue and track its evolution makes for a perfect start point that it is certainly fully aligned with the "agile manifesto".

Taking the first day's morning to explain the customer what "agile" entails, specially for him -and agree with him on doing it that way (or not, but then you are fred to go waterfall or anything else that better suits the scenario), and the evening to explain both customer and the internal team what DONE means, and a Redmine site for tracking customer-opened issues and the internal team-produced documentation should be more than enough on most cases.

But this is just too cheap and logical to gain traction.

"I end up being unable to do the tasks (stories) assigned during the development period (sprint)"

Bzzzt! Error!

Stories are not *assigned* to the sprint, they are *queued* for the sprint. It might look like splitting hairs, but it's far from that.

Part of the reason d'etre of agilims is that you don't have a crystal ball to see the future. Maybe your team's velocity is not well stablished, maybe you missed the complexity of the task... when planning a sprint you are not *commiting* to complete, say, these five stories, but agreing with your customer that these 1, 2, 3, 4, 5, 6, 7... stories are the most interesting right now and in that order, and that given your current knowledge about yours and your team's abilities and the complexity of the stories at hand you *probably* will be able to fulfill 1,2,3,4 and 5 of them by the end of current sprint.

Once again, the old problem: agile "processes" put on top of the old mentality -like trying those new dancing steps from charleston over the same old waltz. Funny results guaranteed!

"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"

Wait... what!?

You obviously don't know what you are talking about.

Why do you think "velocity" is not interchangeable and it is instead tied to a given group if people were interchangeable? Why do you think "velocity" evolution needs to be referenced just to a given team's history if it could be stated in advance?

"Individuals and interactions over processes and tools" is the first basic tenet of agilism. Why do you think "individuals" is the very first word of it if people were interchangeable and, thus, out of consideration?