Yes, Ken Schwaber basically said this at Path to Agility on Thursday. I think his exact words were "it was just a word that we thought was clever, but it probably has more of an impact than if we had used 'rigid', or some other word."

At the end of the day the Manifesto really says they support collaboration and getting things done over planning and following a process. It doesn't say a thing about any of the practices that have been implemented in Agile's name.

There's also a lot of gaps in Agile and IMO while Stories are great they are not a substitute for fully defined requirements analysis.

I hate to break it to you but "fully defined requirements analysis" is a pipe dream filled with rainbows and unicorns. I have never, not once, seen a requirements document that accurately captures exactly what the system will do. Even if it did it would be true for all of 5 minutes before the product owner/user changed their mind and redefined what they want. The whole point of stories is to do things in small, end-to-end slices to produce functionality quickly, let the product owner see it and play with it and then get a better idea of what they really want. I know what you're going to say next: "If they keep changing their minds then how does it ever get done?" Simple, you make it extremely clear that continuously changing their mind directly equates to more time and money spent and prevent other functionality from being implemented.

The key stakeholders either don't pay attention or louder voices who have really no relative bearing to the project somehow get suddenly important. These are often folks with something to gain by holding things up or creating confusion. That is always the problem in all projects but it seems more acute in Agile because "hey, we have a process that can allow for these changes."

You're right, this is true on all projects. Stakeholder involvement has to be managed just like any other aspect of a project. As for "we have a process..."; if you think Agile is about processes then you really don't get it. Agile isn't about processes, it really is about adapting to change and doing what works. If what works is having a daily stand-up and holding team members accountable for for their work then so be it. If it means not pair-programming, then do that too. There are no hard and fast rules.

You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.

You're working with the wrong programmers then. See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone. By the way if you're working 15 hour days it means you're mismanaging your manager and their expectations (and/or you suck at your job).

Water is wet, the sky is (perceived as) blue, the world *did not* end, etc.

On a more serious note I wouldn't describe any of the code examples I encountered in school as perfect or "well-thought-out" specimens." Nearly every one of them was a trivial case which ignored most error cases and expected the client human/system/software to be well-behaved. I've often thought that Comp. Sci. students (3rd or 4th year) should be forced to pick up someone else's code and refactor it into something workable. I'm not talking about the disgustingly huge and unmaintainable messes that we work with out in the real world, but something big enough to give them an inkling of the kind of scope they'll be expected to deal with.

I also think that if you're not learning TDD in school these days you're not getting your money's worth, and you'd actually be jeopardizing your career by not learning this early, as it is a life-saver out in the real world.

I was in and out in about 20 minutes, so my experience was fairly quick. There was a Somali lady in front of me who might have had a more interesting time of it however. I made some small talk with her, and she told me it was her first time voting, as she had just married her husband, an American. I asked her if this was the "F - K" line and she nervously told me that yes it was, but kept repeating "This is the line, be careful, be careful!" as though they wouldn't let me vote if I accidentally got in the wrong line. She was both proud and afraid of the whole process. The interesting bit of this is that when her time came there was some activity, and I made out that she couldn't read the ballot, and wanted to know if her husband (who was also in line) could read it for her. I didn't hear the rest though, as it was quickly my turn at the polling station.

I haven't had a chance to look up the pertinent law regarding whether someone else is allowed to read the ballot or not, but I would imagine this same scenario has played out many times over (This isn't an argument for or against ballots in multiple languages, just an account of a polling incident).

Congratulations! You're in the process of joining the human race by displaying a sense of self-awareness and an awareness of other's feelings! You've already solved half the problem simply by noticing that you're acting like an arrogant jerk. Next step: When you notice you're about to say or do something arrogant or jerk-like just invoke Wheaton's Law.

Where does it come from: As for where it comes from it is pretty easy to see. Most hardcore nerds spent their youth getting picked and teased for being hardcore nerds. Get them into a field in which most people still regard as Voodoo/High Wizardry (Come on, you have to admit that even though people in general are more familiar with tech now most of them are fairly ignorant of how anything tech-related actually works. This is not a dig against anyone, it is simply a statement that most individuals don't know or care how a given piece of tech works, just that it does.) and it is easy to see how a level of arrogance might develop.

Rectifying it (Issue status - Won't Fix): Luckily this is a self-rectifying problem. Once said arrogant jerks get out into the real world most of them will go through the post-grad school of hard knocks. No one wants to work with an arrogant jerk. A lot of them will either self-correct their behavior and try to play nice with their co-workers, family, friends, etc. The rest won't have enough self-awareness to see what is causing the problem in the first place and will quickly either be out of a job, spouse, friends, etc. Problem solved either way. I've seen both scenarios play out.