Team Foundation Service Update – Dec 10

re: Team Foundation Service Update – Dec 10

Brian Harry MS — Wed, 02 Jan 2013 15:57:32 GMT

I've asked a couple of people for ideas. My first guess is that it might be an https/port 443 problem. I'm guessing that this may be the only https site you've tried using from that VM.

Brian

re: Team Foundation Service Update – Dec 10

Having a strange problem — Mon, 31 Dec 2012 01:39:18 GMT

I have one virtual machine running and which is connected to a domain controller (virtualized). I can not access http://tfs.visualstudio.com from IE inside this machine. However i can access any other site. Why is that so?

re: Team Foundation Service Update – Dec 10

Dave Ritchell — Wed, 12 Dec 2012 21:01:26 GMT

+1 for consistency. Stick with Source...code feels like the wrong term especially for all of the SSIS packages we keep in TFS from our DBAs.

re: Team Foundation Service Update – Dec 10

Brian Harry MS — Tue, 11 Dec 2012 10:54:42 GMT

@Matt, We won't be changing the fact that TFS is file type agnostic.

Brian

re: Team Foundation Service Update – Dec 10

Matt Zirksey — Tue, 11 Dec 2012 03:51:47 GMT

We store a lot of other types of assets in our TFS source control, we don't use SharePoint so we have our managers checking in Visio workflow files, word/excel/PowerPoint documents, and we have our designer using blend to check in sketchflow screen flows. Calling all of that work code would make it seem like we should be storing those files somewhere else, SharePoint is too expensive and we like our TFS server(we had everyone checking into VSS before and all they knew was version control good/network drives bad). Version Control\Source control is file type agnostic which works for us. Please keep it the way it is.

re: Team Foundation Service Update – Dec 10

Bill_G — Tue, 11 Dec 2012 01:48:02 GMT

Please make 'Code" a universal term instead of 'Source' Consistency is important

re: Team Foundation Service Update – Dec 10

Brian Harry MS — Mon, 10 Dec 2012 22:47:08 GMT

I appreciate the follow up with the detail Scott.

Brian

re: Team Foundation Service Update – Dec 10

Scott — Mon, 10 Dec 2012 22:28:33 GMT

Matt,

Maybe I was a bit over the top, wait I take that back, we have invested heavily in TFS 2012, and so seemly small changes like this have a huge cost associated with them.

And in the end is 'code' any better a term than 'source'? And why the change, and why the change now?

Let me help you feel my pain around this, our offshore contractors are constantly changing (average contract time is less than 6 months), so any changes we make to our TFS environment need to be thoroughly reviewed and approved by the offshore company's management so we've invested heavily in building our training content, hundreds of screenshots, hundreds of videos, dozens of help desk escalation documents. Hundreds of thousands of dollars in investment. REAL money. And REAL benefit, what used to take a contractor 4-5 days to get up-to-speed on our environment (TFS Access / Developer Image/etc) is down to a matter of 2 days (~8 hours of configuration time...plus 8 hours of training time (we force them to watch videos, sign off on documents with screenshots), so now our contractors don't have any excuses for not being able to write code and have to "sit and wait around for a week or so".

So sure I like the term 'code' as much as the next guy compared to 'source' but when everywhere in visual studio it's called source this, and source that, why the change?

Why the inconsistency?

Either change across the board or don't change this in a haphazardly fashion.

Just think of all of the questions to our poor developer support help line, "source control explorer is gone, all of our source code is missing", "click the code button", "what where?", "wait I'm in Visual Studio and I don't see a code explorer, where do I find the code explorer? oh what I found it...wait no that's the Architecture tool for exploring code."

Now we have more and more of our offshore folks using web access, not only for work items, but we keep finding that our offshore folks who can't use our corporate image (thanks Microsoft licensing) who can barely get VS installed properly in 2 weeks so we're pointing them to web access. That means for things like code reviews, merge conflict reviews, build kick offs, etc our offshore folks are using web access more and more.

And so we have to document the living day lights out of how to navigate around the tool and so changes like this just seem randomized.

Again, I may have over reacted and heck maybe the answer is we just don't move off of Update 1, but if Microsoft makes this configurable then we'll have the ability to move to Update 2,3,4,beyond and slowly work to get our offshore folks trained.

Change for change sake won't help me sell this to my management team...what's the benefit? What's the ROI they will ask me? And so I'll ask Brian the same question: Why?

re: Team Foundation Service Update – Dec 10

Brian Harry MS — Mon, 10 Dec 2012 22:10:05 GMT

Yeah I have to say I'm a bit taken aback by the fierceness of the reaction to the change from Source to Code. The marketing bozos, ahem, I mean team had nothing to do with the decision, BTW. I'm happy to let them take the flack when they make controversial decisions but this one was all on the dev team. I think the change from Source to Code is a bit arbitrary but I think the team felt that word captured it a bit better. You're right though, we won't be changing Source Control Explorer to Code Control Explorer. I'll talk to the team a bit more about it and see more what the thinking is.

The change in order, I think, was much more deliberate. The change certainly wasn't in any notion of order of operation. It's one of prominence or frequency. It's also more a statement of the future than a statement of the past/present. I have to be honest that our source code (how's that for getting both words in there?) experience in the web UI has generally been a bit of an afterthought. In fact, I've described our web UI as the primary TFS interface for non-developers (with VS/Eclipse being the primary interface for developers). We've invested heavily in fine tuned project management experiences (and plan to continue to). However, we are also signalling the intent to make the web UI a great place for developers too. I mentioned that we'll be making a concerted effort in the coming months on our source code experience. You'll likely see a much richer and more pleasing experience (and faster, etc, etc). I'd say stay tuned for a bit on that and see if it doesn't start to feel natural. If not, we can consider moving it back. After all, it's only about a half an inch away on the screen (ok, an inch if the change Code back to Source :)).

*** No, I'm not taking the feedback lightly. I'm serious about considering it but if you can't poke a little fun at things, life is pretty dull.

Brian

re: Team Foundation Service Update – Dec 10

Matt Ring — Mon, 10 Dec 2012 21:37:22 GMT

How well does that sarcasm-filled vitriol work in your other arguments at work and home, Scott? You win a lot of arguments that way?

@Brian, I don't really mind the wording change from "Source" to "Code". I didn't see a need to change it in the first place, but it feels like semantics. As to the ordering, I do take issue with that. I would disagree with the argument that "code" comes before "work". In my experience with using Web Access, I tend to go into the product/sprint backlog prior to doing any code; therefore, I need to define my "work" before I start to "code". And the coding tab only comes into play after the actual coding has been completed/checked-in.

So if the idea is that the link order mirrors with the development lifecycle, it seems like the original order made more sense:

Work -> Code -> Build -> Test

If the ordering is based on frequency of usage, I typically use SCE over web access to query changeset history / diffs so my input wouldn't be very valuable here.

My two cents. Thanks.