I have always attributed this to the "it's a sample" mentatility. In samples you variables named myObj and newVar and stuff. You should not name things like that in production code, and neither should you use single letter small scope variables. While I have seen both in production code (really, you named the search parameters myString?), I discourage their use (even in linq) in favor of more descriptive names. Perhaps we should insist on better quality examples for teaching these technologies to help instill better habits in new and learning programmers.

I suppose it did read a bit like an ad, but then, when people have experienced something that they felt was good and they are trying to convince others that the particular experience was good, and it might work for them, they tend to proselytize a bit and it comes off sounding ad-ish. I am not really sure what you are getting at with you middle paragraph. Yes, I suppose it does boil down to a sort of waterfall in a month except the initial specs came out long before the start of the 2-week sprint, and we weren't building the whole application in one fell swoop.

Quote:

Specs should be clear (call them stories!) and be frozen for the month (woaah!).

I am not even sure what I am supposed to take away from this. Is that sarcasm ("woaah!")? Our specs were frozen for two weeks and we made sure that we had everything we could think of speced out. One thing I hated was implementing one way and having to go back and change it due to misinterpretations or omissions in the spec. And it would seem to me that having the specs frozen during the sprint would be a good thing. Do you enjoy having someone come back and change the size of this and the color of that and the placement of this other thing several times a day?

Quote:

Aw, and you need a domain-expert to validate your assumptions.

What assumptions? And who is this domain expert you speak of? I just don't understand your sarcasm.

I have worked in a couple of teams that used varying levels of "Agile Practices". The one that followed it pretty close to the book but still allowed a little wiggle room worked the best. We got scads more work done and put working software out on time and often ahead of time because of it. I think that part of this is due to our culture. At the beginning of the Agile/Scrum effort, the software team had been consistently late on a particular project. This was mostly due to scope creep. I am working on the Product page, and the person who eventually become the Scrum Product Owner would come by wondering why the Contact page wasn't finished, and tell me to work on that instead, a couple days later it would reverse. When we implemented we decided to have a little fun with it. A jar was set up and any time the product owner wanted something changed in the middle of the sprint, it cost him 10 bucks per complexity point. If there was something that was actually an emergency that was forgivable, but raiding the sprint was forbidden and he would pay dearly for it. Secondly, we padded our meetings out and planned the hell out of things. Our Beginning of Sprint planning meeting would routinely last 3 hours and was complete with Youtube video breaks and brunch from a rotating list of sources. We were allowed to name the sprints all manner of offensive things. Thirdly, we locked down permissions on the issue tracker for the Product Owner. He could create items. He could flesh them out and add screenshots and stuff. He could not create tasks, and could not assign it to anyone, or put a complexity to it. We were the developers, we decided complexity. We decided who did what. So far as the group was concerned, the Product Owner was only the source of features and issues. We had the support of our VP of Technology and that gave us the leverage to institute the changes above. The first sprint or two, we delivered on time and a medium amount of work. after that, we kept increasing the amount of work until we felt like we had reached a good limit, and it turned out we were probably getting twice as much done ahead of time. Now, I will admit that the Product Owner did not like being shutdown. He fancied himself a developer, but was not one. But once we started really moving along, he conceded that this was better, and started treating the team to a lunch at an establishment of our choice at End Of Sprint. I think the big problem with a lot of teams is that they don't get everyone on board with inc

I think in that case, it comes down to standard of living at the work place. How well can the person live at the workplace. I would bet that living in the office at Google is really nice compared to living at the factory complex in China. Mind you, I have never been to a Chinese factory or to China for that matter.

If these are California-based Googlers then I would say it saves them a heck of a lot of money. Rent is terribly expensive over there (but not as expensive as buying).

I have used it quite a bit. I have 3500 rep, have answered 195 questions and asked 65 of my own. I have been downvoted before, a few times rightfully so, a few times without explanation. As with any community there are bad apples who will downvote someone for no real reason, and there are others who, due to the lack of tone on the internet perceive an incorrect tone in a post and downvote for that. I will admit that there is an English bias on the site and non-native speakers who do not make themselves clearly understood have a hard time, and are unfortunately downvoted because of it. I will also admit that I have seen some downvoting issues that were unwarranted, and they were dealt with through reversion. Most of the cases of downvote oblivion that I have seen were from people posting a simple explanation of a problem with no background, no code, no evidence that they have done anything to solve it themselves and then they demand answers. My first question, when I had no rep, got downvoted, I used the experience to better my question and I received a thoughtful and educational answer because of it, and an upvote which made a bit of an improvement (downvotes cost 2 rep, upvotes give 10 rep IIRC). The site has worked wonderfully for me. Now, my question is, any of you who say the site sucks, have you gone on Meta-Stackoverflow and voiced your concerns? What was the outcome? While I am not personal friends with the moderators of either site, they have listened to my concerns in the past and I am not a power-user or top contributor. The above is not meant to put you on the defensive. I am not attacking you. I genuinely want to know, because I frequent the site, and want to know specifics in an effort to make it better. Lastly, you can change a vote. I have done it myself not two minutes ago (as a test). Questions with answers can be deleted but the deletion has to be voted on. And I don't see how not being able to edit a comment detracts from the quality of the site. It keeps people accountable for what they say to a certain degree. 5 minutes is enough time to read 500 characters to ensure that it was punctuated and spelled correctly and is grammatically correct, and after that if you called someone a jackass it's there and can't be taken back.

http://stackoverflow.com/users/1535478/jennifer-marsman-msft[^] http://stackoverflow.com/users/471760/julie-lerman[^] http://stackoverflow.com/users/148870/amber[^] To be fair, I am not a woman, and I don't know the discrimination of women firsthand. But I am a StackOverflow user, and have had a number of very good and useful answers from the women there, and have never seen anything to suggest there was a discrimination problem. Just write good questions and the answers will flow.

I have never had any issue on SO. Most of the downvoted questions that I have seen have been because OP asked a question that is covered by 10 other previous posts, did not show any work, is vague, or is asking for recommendations that are often going to be biased. If, however, you do research and ensure that there are no other answers on SO that fit your situation, AND you create a well written post that shows what you have done, shows where you are having the problem, explains what you THINK is going on, etc, it will get answered. I have found that if I write my post, and look at the right hand pane there are a bunch of suggestions, and often I have found my answer there without posting, maybe 10 our of 15 times.

I did not buy Visual Studio for a polished look. I want something that is there when I need it, and gets out of the way when I don't. I have found VS2012 (2010 also used WPF BTW) and VS2013 to be pretty good about that. The ui elements do not draw any undue attention to them and I can focus on my work. Additionally, I have some degrading eyesight and the Dark Theme in 2012 and 2013 work wonderfully for me. The monochrome-ish design supports the dark theme. Too many colors would make the dark theme unusable.

What you are talking about is more of a XAML nature. While XAML is a part of WPF, it is only the popular method by which WPF user interface items are expressed. WPF itself has a lot more to do with performance, binding, and event handling than just XAML. For instance, WPF offloads almost all UI display processing to the graphics hardware, while Windows Forms relies on the CPU to process each repaint. WPFs binding ability, arguably one of it's neatest and most useful features allows for true (and fairly simple to implement) separation of concerns between application logic and UI display logic. I will also say that the UI elements have a very good dynamic sizing engine built under them. I could never have done some of the things that I have done in WPF with Windows Forms.