in

ASP.NET Weblogs

Chris Menegay's WebLog

My thoughts on NTeam

There's been a lot of coverage on NTeam lately, and I guess it's time to give my thoughts on it. While I applaud the ambition these guys have, this whole effort seems like it's done out of spite.  If NTeam is such a great idea, why wasn't it started long ago, rather than just after VSTS pricing was announced?
 
My personal opinion of this project is that the end result (if ever completed) still won't be as easy to use or integrated as Team System. It can't be, it's made of bolting together a bunch of separate applications. That's been Rational's problem, and I don't think they've figured that out yet - even with IBM's money. And while lack of integration may not bother people, it should, because that costs TIME.  Some people (and companies) seem to have more time than money, so they don't mind using their time to save money. In my opinion, these companies are simply overstaffed (I feel a flame coming on).
 
The biggest cost on development projects is not tools, it's staffing. If the average salary for a project team member is $70K, when you factor in benefits and overhead (taxes, office space, equipment, utilities, etc.), that person is probably costing you at least $80K (likely more, but we'll assume you work standing up using a Pentium II computer and you don't have A/C in your office). If that person works 1880 hours a year -  40hrs/wk, minus 25 PTO (15 vacation/sick days and 10 holidays), they are costing $42.50 an hour. Again, these are very conservative estimates.
 
So, lets assume a team of 10 people (mix of developers, testers and project managers).  If each person spends TWO HOURS (a small amount) a week because the NTeam products require more effort than VSTS, that costs $44,000 a YEAR.  It could be argued that 2 hours/week is high.  I've seen projects that use a lot of open source tools patched together, and I personally think the number is probably much higher than that. However, it's not 2 hours for each person, it's usually some of the most highly paid team members doing a lot of work configuring and supporting the tools each week.
 
Also, from what little I've seen of NTeam, it sounds like they are going to patch together a bunch of developer tools. To really be an alternative, they also need:
  • A portal site simliar to WSS
  • Reporting
  • Built-in support for process
  • Distributed load testing
  • Integration with Project and Excel
 
So if you factor in TIME, I think NTeam will likely be a more expensive product, and it won't be as nice.  Of course, I'm building a services offering around VSTS, so I'm a bit biased. However, from the sounds of it, there will be more services opportunity per install of NTeam than for VSTS, so that doesn't really matter to me if NTeam is successful. 
 
I'm curious to see how all of this plays out. I personally think NTeam will never come out in a version that meets expectations. The burden placed on these guys by trying to match features with VSTS will be huge.  This is just a massive undertaking.
Published Apr 14 2005, 09:56 AM by cmenegay
Filed under:

Comments

 

Anderson Imes said:

Right on. I agree 100%.

People don't understand that what they are paying for here is productivity, ease of use, and streamlined interface and processes.

A large amount of the basic features that Team System offers to developers are really already on the market in some form or another. There are a lot of companies that take a sack full of these tools and implement them in their process to great success.

I think that it's great that you point out the real value in TS. Streamlined integration is what you pay for with TS.

NTeam, unless the project works toward complete end-to-end integration across products (implemented with complicated add-ons to VS, etc), is going to provide a product that is perhaps easier to deploy than the "sack o' tools" method, but in essence really redundant.
April 14, 2005 12:42 PM
 

Charles Chen said:

*Disclaimer* I'm not a "fanboy" or a Microsoft hater (in fact I work for a Microsoft Solutions Provider).

1. It would seem that there are people, like you, who seem to think that VSTS is a magic bullet that will, all of a sudden, increase developer productivity 150% overnight! VSTS is not a magic bullet. VSTS does not make up for bad project managers, bad developers, bad thinking. Gosh! How did people *ever* make good software without it?! But Microsoft is certainly pitching it this way. Also, you have not factored in the cost to acquire new licenses and training for all of the new features of VSTS. The training itself will cost on the order of thousands of dollars, even for a small team, not to mention the lost time due to the training.

2. There's always a place for alternatives. Gee, I guess MSSQL Server is soooo great, we should just forget about all other database systems like MySQL. So you think that just because it's Microsoft, it's better? Visual Sourcesafe is obviously the *best* version control system too, right???

3. There is no expectation on NTeam; it's free. Every features is just another added bonus. How can anyone complain? "Well, it doesn't have such and such feature!" Well, it's free. "Well, it's not as easy to use." Well, it's free! How can you argue with free? I know I can't. If someone gives you a new Kia for free, will you refuse it because it's not a BMW? Assume that, for the sake of discussion, we can quantify how "streamlined" and "integrated" each solution is. Even if VSTS is 15% more streamlined/integrated than NTeam, does that make up for the $$,$$$.$$ you spend on licenses, training, time off for training, training material?

4. Integration will be better than you think. Look at NUnit and TestDriven.Net. I, for one, thikn that it's very well done. Look at ReSharper...that thing rocks (albeit not free).

5. "People don't understand that what they are paying for here is productivity, ease of use, and streamlined interface and processes" So you're saying that Microsoft actually knows something about this? Strange, I've never felt productive going back and reformatting my HTML after VS.Net designer mangled it. I dunno, to me, that's a waste of time. But I guess, that's "productivity" and "ease of use" in your language.

6. You haven't factored in support and support costs. NTeam support will be widespread and *free* because it will have a larger userbase (not to mention that this userbase will inherenently be more inclined to share knowledge for free). VSTS support will be an added cost to the bottom line. And, as businesses will be slow to move to the new licensing model, intial uptake and consequently open/community support for VSTS will be slow and sparing. Merrill Lynch is still using .Net 1.0 VS.Net 2K2. In fact, they haven't even converted/ported all of their apps from ASP yet!
April 14, 2005 1:30 PM
 

Charles Chen said:

To add to point 1 (in anticipation of a rebuttal), I would not consider training costs to be the same across both solutions.

The reason is because the company has an initial investment in VSTS; it's something they already paid for so they (CTO, project managers, etc.) are willing to pay for training for it. On the other hand, if a team decides to use NTeam, there is no initial monetary investment. There is no need to worry about ROI. Managers won't feel pressured into accelerating the process of training for NTeam. And, more than likely, there will be much more community support for NTeam (see point 6), which will make training more affordable (if necessary at all).

Also, it's likely that the first teams that would choose NTeam over VSTS are teams that are already using one of the existing NTeam components, which would imply that they have no problem learning and utilizing a non-Microsoft product. I would argue that said teams have developers/managers/architects who are more motivated to learn on their own.
April 14, 2005 1:44 PM
 

Chris Menegay said:

FUN!!! I love debate!

1. Sure there is training involved. There's training involved with any new product, either formal training, or learn on your own. The documentation with NTeam won't match what will be available with VSTS - the amount of formal training and books available won't compare either. That means you'll have to spend many, many more HOURS learning NTeam, because you have to learn it on your own. Some people don't mind that - they have more time than money. Those types of companies rarely invest in training for their employees, and that is their choice. I think it's misguided.

2. First, NO ONE (I hope) is going to say sourcesafe is a good product. It's crap - I take that back, it's fine for very small teams, it's just that people use it for very large teams (against MS guidance). There is a place for alternatives, that doesn't mean that people are making smart BUSINESS decisions by adopting them in many cases. Example, I could walk everywhere I go, however, I have decided that MY TIME is valuable enough that I own a car and use that. Many companies adopt the same concept of buying time. I personally think they are the most successful. I will make the point that prior to VSTS, I didn't believe there was a good option to buy some time for software lifecycle improvement. I think the open source market and the tools there WERE the best option, but you were investing TIME for TIME, hoping to get a return - and I believe you can. I just think it's a better investment with VSTS.

3. There are expectations on NTeam, I'm not sure how it happened, but this is from eWeek: "A team of developers has started a project to create an open-source alternative to Microsoft Corp.'s Visual Studio Team System". That sounds like an expectation to me.

4. Integration?? You are missing the point, and I question whether you've really looked at Team Foundation Server. UNIT TESTING is a itty-bitty piece in a large puzzle. If that's the focus of NTeam, so be it, don't even position it as an alternative to VSTS then - just a dev tool at that point, not a lifecycle tool.

5. Skipping this - if you are unproductive in VS, then switch tools. Maybe Eclipse is more to your liking?

6. I have factored in support costs. Support costs for open source products are more expensive because they cost TIME. If I have a support issue with a MS product, I pick up the phone, pay my $250 (assuming I don't have MSDN and bundled calls) and get the problem resolved. If I have a problem with an open source product, I have to HOPE someone cares enough to help out. If not, I have to figure it out, or code myself out of the problem, which equates to time. As for there being more support for NTeam, I doubt it. Just look at how much of a headstart MS already has. I expect more people to be on VSTS in 2 years than on NUnit - for companies, it's not really that expensive - companies spend more money than this all the time. They are trying to be more productive.

I totally don't get the point about not converting ASP apps over to .NET. Was there a point there? VB3 apps still exist, mainframe apps still exist. Is that Team System's fault? Obviously VSTS is targeting new development, as it's tied directly to VS2005. I wouldn't suggest you go back and try and use it for ASP. I would suggest trying NUnit there either!
April 14, 2005 2:18 PM
 

Dean Harding said:

The problem isn't that companies can afford VSTS, it's that consultants *can't*. MSDN Universal has always included "developer" versions of the various MS products which let developers code against them and become familiar with them. For production systems, you still had to buy the full lisence.

But a consultant is unlikely to pay the extra couple of K to buy VSTS, and if he's not going to buy VSTS, then how is he expected to recommend it to the company he's consulting for? A one- or two-man team isn't going to see an extra two hours a weeks lost as an issue - they're going to see the thousands of dollars saved on initial investment.

For a small team, $80/week per person (which is the time lost due to non-total integration) looks much better than $4,000 in inital investment. Even if it's $80/week for ever. Why do you think people are happy to rent a $5,000 TV when they could just save up for a few months and buy it outright?
April 14, 2005 9:53 PM
 

TrackBack said:

April 14, 2005 10:33 PM
 

Peter Munnings said:

I think we are all forgetting that VSTS is aimed at the Rational end of the market. Companies have been paying big money (and obviously justifying the expense) to have full SDLC package.

VSTS is going head to head with Rational Clear Case, Clear Quest, and parts of XDE. A company that is used to making a big investment in life cycle tools will certainly consider VSTS, but I think is unlikely (at this stage anyway) to look at an open source solution for critical data. We are talking about source code, and work items. Hardly things you want to vanish or get corrupted and have no recourse back to a big company with lots of support.

From a training perspective - these big companies rarely spend all their training budget anyway, at least now there will be something worthwhile to spend the money on.

I think what NTeam may do is get people who have never had SDLC tools to start using them, get used to them, start relying no them and then probably make the investment to purchase VSTS so they can have the reliability of the Microsoft Support and guarantees.
April 15, 2005 2:24 AM
 

TrackBack said:

Cenov
April 15, 2005 7:36 AM
 

Chris Menegay said:

A couple of quick responses.

Dean - I honestly don't think Microsoft realized what they were doing from a learning perspective with Team Foundation. I know they've heard the feedback and are mulling that problem over. I personally think a long (6-month or so) "trial" version would suffice for the learning aspect. If you can't learn what you need in 6 months, you have other issues. If you need it for longer than that, you are really using it in production and should pay for it.

Peter - First, it was your email that started this ;-) Second, I don't think MS is only targeting the Rational end of the market. The pricing almost makes it feel that way, but when you talk to people at MS, they really think they are going to create a whole new market for lifecycle tools, and I think they are correct. I've talked to a lot of customers that are interested in this, and very few have a complete set of tools today. The other thing MS is obviously trying to do is drive subscription revenue by getting people to buy MSDN to take advantage of the upgrades.
April 15, 2005 8:54 AM
 

Thibaut Barrère said:

NTeam could sound a bit like the .Net version of MyEclipse (http://www.myeclipseide.com/), which is basically a distribution of open-source plugins for Eclipse.

When doing J2EE development I rely on MyEclipse, which comes for a very small fee (30$/yr). This stuff is getting really popular amongst J2EE developers.

I think the tricky point here is that it's more difficult to extend VS.Net than to extend Eclipse!

I hope to read more from NTeam soon.
April 16, 2005 1:04 PM
 

Jason Bentley said:

Well, obviously, commenting on success/failure at this point is premature - on my part and on yours. The only parts I will comment on is the spite comment and the cost of learning views. You are totally off base and you should do some reading before posting things like that. And, obviously, you should listen to what the project members are saying about our goals and vision instead of what you may be reading else where. If you look at http://geekswithblogs.net/jbentley/archive/2005/03/30/27755.aspx you will see that I DEFENDED Microsoft's call on pricing before beginning the project. I have not posted a single comment out of spite and the project was not started for that reason. I want Team System and cannot afford/justify the cost. With that said, we will build one. As for training, I find it hard to believe that any new application is a silver bullet. If developers aren't using unit testing tools at this point, a new application package will not help you adopt it unless it is mandatory. However, if a deverloper is all ready using NUnit or NAnt, there is NO additional overhead to learning these packages in NTeam. That will significantly decrease the total cost of ownership for NTeam. Don't you agree?
April 17, 2005 3:38 PM

Leave a Comment

(required)  
(optional)
(required)  
Add