Rick Laplante - Talking about Visual Studio Team System, Part I

The question is asked "how many developers do you need for these tools to be effective". This question come on the back of a short explanation of code coverage.
Instantly I said ONE. Code coverage for a solo developer would be great. It is so easy to get into the habbit of testing the app in the same way each time. Being able to see that you were missing something would be such a help.Shame it will cost too much for solo devs to buy.

Charlie

CplCarrot wrote:

The question is asked "how many developers do you need for these tools to be effective". This question come on the back of a short explanation of code coverage.
Instantly I said ONE. Code coverage for a solo developer would be great.
[....]

Charlie,

I've found some good side of such a high pricing. Currently huge corps have a lot of people working on thouse lame tasks like a testing / code coverage / review / documentation / ...

Team System promise to make it as easy as "Click Here to Start" inside Windows 95. Thus - in case if it will be allowed to use entire product effectively by a single developer - then all others people will be fired (think about - most of companies now think about cost saving - not market share increase).

So - if thouse tools will requere 5 persons to using them - then 5 people will have a job. PAID JOB !!

You have to train yourself to find something good in any event.

Update: I won't be able to get the licensing video up today, due to a technical problem. I'll get it up on Monday. The second video, about VSTS licensing, though, is available for download here. Sorry about that.

Great news for the individual consultant on Team Server pricing here. I know precise details haven't been fleshed out yet, but it's great to know Microsoft are looking at the issue.

Thanks for listening!

Here I was thinking everyone at MS had to talk in a scripted manner, never giving an honest opinion, always starting an answer with "so...", never swearing.  Having him refer to a product as "kickass" lifted a good portion of that stereotype.  Imagine my embarassment when I realize "Wait... These are just people... just really good people."

I actually heard one guy swore "we really screwed up.." (the 1.0 framework). Anyhow, it seems a part of the video got cut off when he said that "people always enjoy this story". Yup, we take mental notes so whach out what you say

OK, so I'm happier about the VSTS pricing now this guy's explained it and I'll be very happy if Empower ISV partners get the full suite as he implies.

I do think he needs to investigate other dev tools a bit more when comparing prices. The VSTS pricing may compare well with stuff from Rational but there are much less expensive tools around that do the same stuff. The appeal of VSTS is that all the aspects are integrated in a way I can't get with the range of tools available from what are mostly other small ISVs. I'd really like that integration but I'm not paying big bucks for it.

The licencing interview is a real jewl in economies behind software developing. One thing that was clear is that investment has to be recuperated.
I think that the investment will be recuperated now or never as I belive this kind of integration will become focus even for free projects. Projects like Eclipse could bring products equivalent to Rational's suite or TS in rather limited amount of time. Many tools already exist and there's always Ant, Maven, Subversion, Bugzilla, trac, xUnit, ...
On the other hand I don't belive MS can loose the investment as they actually made a system that will help them build better software and it's MS's best pay-off.
PS. My own personal question, if I have a versioned project in SVN, how is migration done? Can I keep SVN (as I like it a lot, and have a lot of history in it)? I attended a TS event and the MS guy said that many ISV's are developing plug-ins for the TS studio, is there some group that could help me use SVN?
Doesn't MS think that plug-in based developing made eclipse what it is today (not counting the big companies behind it) and effort should be made to make it more mainstream? That way, we can push the lower bount of the market penetration even further as development would/could/should happen without cost to MS.
All that said, I'm not a Java freak
There is a one more thing (but this is just off the wall), what would happen if you set up a TS farm site? (read sourceforge)
That way people would not have to buy the server and still be happy with the clients, not to mention the proof of scalability that you'd like to get. Just for Open Source projects of course (or closed if they pay)

I thought the discussion about market penetration/pricing model was flawed.

One of the fundamental reasons that the market penetration for tools produced by the likes of Compuware et al is so low is the cost.

I have worked for big (70,000+ employee) and small (8 employee) organisations and the "good tools must cost a lot" argument in my opinion doesn't stack up.  Also I've found bigger organisations actually spend less per developer.

You want market share - stack em high - less em cheap to paraphrase a well known saying.

Incidentally here in the UK the predicted cost (around £1700 = approx $3000 US per user) of Team System made the front page of Computer Weekly.  The article made the point that at that cost not many people are going to buy into it.

Rick (along with many MS executives) doesn't seem to articulate well what Code Coverage really measures, and just how fundamentally flawed the metric is.

The notion that Code Coverage measures test effectiveness (the degree to which an activity is successful in achieving a specified goal) is not accurate; it simply measures the portions of your binary that have and have not been executed while measurements were being taken.

Code coverage doesn't tell you if your code behaved correctly, and most importantly, just because I executed a portion of the code does not mean that it has been adequately tested, which is why I get irritated when people equate code coverage to 'effective' or 'good' testing.

A simple example: I can choose n number of values to throw at an API that does a simply calculation, and verify that I have 100% code coverage for that API, but that does not mean that there aren't bugs in the code. Just as easily, I could come up with another value to give to that same API that causes a divide by zero or overflow error that is executed by exactly the same code path.

Don't get me wrong, Code Coverage is a useful tool; the most useful aspects are analyzing results over time (is my coverage increasing or decreasing as new code and new tests are written?) , and it can tell me where I have holes in my testing. But effectiveness of my testing? No.

Code coverage is a tool.

I watched the video.  I took the code coverage "coverage" for what it was worth.  While it's not the best testing tool that can be built, it IS useful.  Any developer worth a paycheck understands its limitations and benefits.  I don't recall hearing any unrealistic claims about code coverage's capabilities.  So, rather than slam it, perhaps we should applaude the team for doing something positive rather than doing nothing?  I fully expect the next Visual Studio to take the next step.  Code coverage detection isn't easy.  The next step in automated testing will certainly be more difficult, say: Validate that methods are called with every conceivable combination of parameters?  Validate that all of your exception handling does what you expect?  Working on an automated testing solution that would excersize parameter boundary conditions certainly would be interesting.

My biggest hurdle so far has been the "day one productivity."  Just figuring out how to do simple tasks, like follow the MSF for Agile template process, is painful.  I haven't been able to find much in the category of "Perform steps A, B, C, ..." to get started.  When I do, it's unclear, like "Start the web form designer."  What's that?  After a bit, you discover that it's just Visual Studio.  It seems like such a stupid question once you've seen the answer.  Why not just say, "Start visual studio."