Lazycoder

Visual Studio Whidbey and team services.

Dana Epp’s ramblings at the Sanctuary : Team System Testing: Microsoft just might have it right
Overflow from the VSTS demo last night
Geek dinner turns into “late night with Burton team”
Visual Studio 2005 EDT- Overview in Building 42
Late Night Talk on Visual Studio Team System
Geek Dinner Report

Not everyone at the dinner got to go, you had to be sitting at the cool kids table. I wasn’t I was at the interesting people table.

That’s OK with me. When it comes to Microsoft technology, I’ll believe it when it’s RTM and not a second before. They have a good track record when it comes to grand promises and good demos, but the devil is in the details. So I’ll wait on the EDT stuff until Visual Studio 10 (codename: Marysville or something). It might be stable by then.

There’s lots of other things that may be in the Team Services aspect of Whidbey that interested me, but I can’t really speak about them because:
a) I think I’m under an NDA/contract/some damn legal thing from the usability study I participated in.
b) Those things may not make it into the final version of the product or into any product.

MS marketing does enough foot shooting on their own, they don’t need me pulling any triggers. I’d hate to be responsible for burning out a thousand MVP and MS blogger keyboards as they frantically spin and call “bullshit” because of something I typed.

The one big thing that Jason Anderson kept coming back to was “48 teams at Microsoft have signed up for EDT”. Jack came back with “the team I’m working with sure isn’t”. That will always be the case. Sure the teams are signed up and promise to use it, but do they? Time will tell. If Microsoft won’t use their own tools internally ({cough} MS Project{cough}{cough}Visual SourceSafe{cough}) why should we put our faith in them?

The one point you WON’T see mentioned in any of the other blogs is the point I made about convincing the check writers that TDD and documentation is important. Everyone there who hadn’t ever worked in a business environment or on a business application shut up at that point, which happened to be all the softies. {insert your own ivory tower joke here}. But there’s always a vast gulch between the people that make the development tools and the people that use them. The makers assume that the development of any software is the same, or similar, to the process they use making the dev tools. When that’s not always the case. You can make the argument that testing saves you cost towards the end of the products development cycle. That’s completely true. But when your developer is salaried and the PM has a deadline that is determined by political rather than technical means, anything other than “writing code” is thrown out the window. It’s a terrible way to develop an application, but “get it done” will always triumph over “write good code” in a business setting.

Joshua Swartz points out that this might be more common than you’d like to think