Another day fille with a variety of issues across profiling, debugging and team system. First order of business was attending the talk given by our PM, Gabriel Marius, on building performant and reliant applications with VSTS. At a rough guess there are a several hundred people there.
Despite a few minor issues, Gabriel's talk goes very well. He talks through the variety of tasks that a web developer may be doing to improve quality by doing tests against the ASP.Net codebase and getting code coverage. It's interesting to note that there are a bunch of folks in the room (maybe 10-20%) who know what coverage is and are using it. He then talks to using web and load test tools to identify scale issues. Then dives into using the profiler when running that web/load test, and finding painful performance issues in code. When he asks about the number of folks using profilers, over half the room put their hands up. I'm stunned, I really thought there were fewer in the community looking for these tools, but of course PDC is representataion of the developers who want to continually want the best out of their software, and use a variety of tools to do that. After one glitch, the profiler comes up and profiles web tests under simulated load, and we get a quick overview of the views (similar to Ian's walkthrough). We can easily spot the performance issue in the code, even though for the sake of demo expediancy, the issue is a little contrived. Finishing up, Gabriel shows an interesting security bug found by the code analysis rules that highlights a possible SQL attack. He shows the actual exploit, and then solves the issue with a better piece of code. All in all, response was positive, with spontaneous applause for features like code coverage and load test. We had a host of folks grab us after the talk, and come to the "meet the Team System team" session in the track lounge afterwars. Gabriel did an awesome job of presenting. Many customers loved the fact that we did a great job of ASP.Net integration, that it was very smooth. David and Eric - take a bow.
During the "meet the team" event, Noah wanders up and tells me that our HOL tutorials are ranked 2nd and 3rd for all HOLs in the tools and languages track of labs. This cheers me up immensely.
Matt and I decide to do one last tour of the expo, and see the vendors. First off I catch up with some buddies at AMD and Intel. They've both been having a good show, with Intel doing particularly well with their presentations on ther software tools, which I've seen many people attend. Both vendors have been spreading the word on 64bit and multi core chips, so there is a lot of interest in both of those areas. I wish we had a better tooling story in both of those areas this time around, but I digress. Robert at Intel caught the talk and remarked on how things looked good for the profiler at the demo.
As we wander down one aisle, Matt and I are shocked to see a vendor have a huge "Debugging is Dead" banner across their site. As folks who have a long track record in this space, we're interested to see what's going to make us redundant. It turns out these folks are in the business of moving business logic calculations from Excel spreadhseets into C++ code so they can be reused in other applications or spreadhseets. This protects the code from well meaning CEO's who type in some numbers into spreadhseets they are given and corrupt all those calculations and transient cells. Although I don't do a lot of this stuff myself (although I've noticed to my great concern that I've spent more and more of my time over the last three years in Excel), I can see the value to folks in finance IT and so on. If that's your bag - head on over to savvysoft here. I'm not quite sure there is "no debugging" any more, but I can see how there wouldn't be in that scenario. It was also great to meet another bear's fan (You know who you are Mr. R), and chat to someone from my part of the world (I count Belfast and Enniskillen). Being in New York, he gets a bunch of fellow bears to hang out with and watch the games. I just have to suffer in silence :)
Back at the ranch (aka the tools and languages track lounge), I find poor April has not had time to see the Expo, so I do my bit for the division by being the concierge. My main downfall is that I know nothing about LINQ, and neither can I find enough people to talk about it, although Anders is there holding court. I suppose I do a reasonable enough job directing people to the right folks to talk to. Looking back, i wonder if folks were put off by the mass of blue shirts in the lounge, but you'll have to believe me that we were all hanging out just waiting to talk to customers.
After April gets back, I field about the 200th question I've had on team system pricing. There are a number of resources that go into that here, here and here. However here is my marketing approved summary on Team System pricing.
If you have MSDN Universal, you are going to get one of the team editions as your next subscription. You get to pick your role based edition, either architect, developer, or tester. See one of those web pages for what's in what. If you feel you can't choose, and you need them all, for approx 1000 dollars more you can upgrade to the suite, which includes all three. With any of these individuals and the suite you get a copy of the full server with a 5 person limit for free. If you need a server that can serve more than 5 folks, it costs about 3000. Every role based sku or team suite is a client access licence to a server. If people need access to the server who don't have any of the team editions, there is a licence for that, but I don't know what it costs. That's the best I can do - I wish we had had a printout or flyer that explained it, and that explained clearly what was in what. I'm not going into that here for fear of getting it wrong.
It's getting toward dinner time, and I'm seriously beat and hungry. Doug Hodges spots me and hooks me back up with one of our partners in the COBOL space. We'd had some discussion way back about whether team system coverage tools would work on their .Net version of COBOL. At the time I had said "It should just work, the coverage system is language agnostic." Since I'm in the mood I turn to Sean and say - hey - can I borrow that demo laptop and we can install the cobol on it". However the cobol guy says "err, I gave away all of my COBOL evaluation CDs." However, he does have his own laptop with VSTS beta2 on. I say "let's go for it!" Using the techniques listed in my offroad article here, we successfully instrument and create a coverage file within two minutes (it would have been sooner if I had remembered the correct syntax first). Of course my main concern is that the file won't analyze in the IDE. We open the file, and voila - the coverage result viewer comes up, and the data looks good. We then turn on coloring, and whammo! It's perfect. I'll post a screenshot in a later blogpost with the partners permission. I have to hand this one to the four folks who really focused on CC. Take a bow guys - you know who you are.
Finally, it's off to dinner and the "Ask the Experts" session. Me and the rest of the team head to the Team System table. We notice that both server tables have no representatives, so Chris and I head over an pinch hit for 45 mins till the server team turn up (you know who you are). Most questions are around source code control and it's scale and branching, which thankfully I can answer, extensibility (clueless), pricing (see above) and one that's very interesting to me, the culture shock and non-technical road blocks to adoption. I'm hoping that we are going to produce case studies or white papers on this, but I think I'll talk to my own experience. First, be sure to sell the upside. Explain how team system adoption improves not only individual productivity, by driving quality further upstream, but also improves *TEAM* productivity. Second, be upfront with people about where this may hurt. Going from no process, or a very different process can be a wrench, so identify ahead of time where pain points will be and explain them.
The customer with the perf problem from the day before came back to me. We got his app down from 8 seconds to 100 msecs using the profiler to identify bottlenecks. A quote is coming, so again I feel validated :)
Finally, I meet a customer who is interested in our appverifier integration. It's true that we don't focus as much as we should on this important integration point with the debugger in Developer Edition of Team System. The customer is really trying to figure out memory leaks, which really, AppVerifier is not going to help too much with. What follows are my opinions and not those of Microsoft. In my opinion, no-one does a great, one-stop, solution for tracking down native memory issues on Windows. I've used many of them over the course of 11 years in professional software development, and sadly I think none are great. I pointed him at some of the offerings in this space. Even though the customer was disappointed we didn't have any offering, he was pleased to hear that, yes I understand it's hard, and no - he was not alone.
Sadly, due to logistic reasons, I'll not be heading to the 4 hours of conference available Friday, but I leave with a bunch of ideas on how to get more connection going next time. I hope to see you all at PDC06!