Anders Norås' blog

Thoughts on the Team System pricing scheme

The pricing scheme for Visual Studio Team System has disappointed many .NET developers lately. It is easy to get excited by the features in Team System, but the larger part of the target market for the Visual Studio product isn’t enterprise development organizations and hence do not need the Team System features. Eric Sink is in line with my views on the matter in his comments on the scheme. At Objectware we’ve been using third party products that provide many of the Team System features for some time. The effort to establish a continuous integration framework to support our development process has been sphereheaded by Mads Nissen; who apparently also thinks along the same paths as Eric Sink since SourceGear Vault has become part of our CI platform recently.

I’ve done some experimenting with Team System, including the Team Foundation server during the past six months. The product is excellent, but I’m not sure if it is the perfect solution for a consulting firm such as Objectware. The reason is this; we do projects for a wide variety of clients. With many of the clients we must be prepared to take part in an existing development organization. It is acceptable to introduce a bundle of open source products to use within a product for a client because there is no visible cost with such a toolset. Team System on the other hand has a pricing scheme which forces enterprises to make a choice on whether to use the suite or not. For a contracted project it would be irresponsible to try to introduce such a product. Another scenario would be to run all development projects as in-house projects on our own servers. This would be beneficial because every project within our organization would utilize the same development environment independent of the client the project is carried out for. However there are some challenges with this approach. Most of our projects are developed on-site with the client on their equipment. Many of our clients have their own tool for bug-reporting and similar, but these tools do not integrate with Team System.

As an architect, I would like to use one single product for end to end of the development process, and since I’ve put my time as a J2EE developer behind men, Team System is the perfect suite. However, Team System is intended for large enterprises or large ISVs. To make Team System attractive to consultants, Microsoft must come up with a way to use the product as a backend system for consultants whose client and team aren’t using the product without sacrificing the project management features of Team System.

I don’t think I’ll ever experience this, because Team System simply isn’t meant to be used this way. I think the only sane thing to do is conclude that Team System wasn’t meant to be used by individuals. It is an enterprise development tool. One thing I'd like to see was the unit test features, without Team Foundation integration, included in the Professional Edition.

Ajax, "Chubby" or Smart Clients?

Asynchronous JavaScript plus XML, or Ajax in marketing lingo, has gotten lots of attention lately. Jesse James Garret coined the term in his essay “Ajax: A New Approach to Web Applications”. Ajax is far from innovative. Developers know Ajax as remote scripting. From a thorough summary of different remote scripting techniques and technologies read my post on how to create a Google Suggest like feature with ASP.NET 2.0. This post speaks of a concept called “Chubby Clients”, this is a term I came up with to describe “Ajax” applications. The difference between “Chubby Clients” and Ajax is that I never tried to give the impression that this was something new that I had invented, it was a term meant to underline that applications relying on server callbacks and excessive DHTML usage where fatter than traditional postback based web applications, yet slimmer than traditional desktop clients.

I wrote my first “Ajax” application in late 1996. This application used a hidden frame to issue GET requests to a CGI script on the server. When I demoed this application to more seasoned developers, whose experience reached back to the days of green screen terminals, they were intrigued by the fact that I did asynchronous communication in the modern world of web development. My frames and JavaScript based protocol was more familiar to these COBOL programmers than the request / response pattern of HTTP. This goes to show that there is nothing new about Ajax, neither conceptually nor technologically. When I do my “Chubby Client” presentation I clearly state that the concept should only be used when the request / response model doesn’t provide a rich enough user experience and building a Smart Client isn’t an option.

As with all software, while a simple “Chubby Client” is easy to build, more advanced enterprise “Chubby Client” applications are not. This is probably the main reason why we’ve seen so few successful web sites using XmlHttpRequest to do out-of-band communications between the browser and the server. I’m not surprised to see Google’s top-notch developers creating working “Chubby Clients”; I would be surprised to see “Joe Developer” do the same. Having years of experience with leftfield web technologies, such as different forms of remote scripting, I can assure you that while these techniques solve lots of challenges, creating applications that apply them is time consuming, debugging such applications is hard and supporting them is a nightmare. There is a discussion on The Server Side on whether “Ajax” will render Smart Clients obsolete. It won’t, but the emergence of Smart Clients will blur the boundaries between web applications and Windows Forms applications. This will raise the bar for what kind of behavior users will except from departmental applications, such as accounting systems, developed as web applications. If such applications are to survive as web applications, the user experienced must be enriched. Fattening the applications and transforming them into “Chubby Clients” is a viable option although the best solution is converting such applications into Smart Clients. Traditional portals et cetera won’t have much to gain by fattening the user interface, so they’re like to stay as they are.

Kindergartens and load testing

If you’re a toddler parent living in Oslo and wish to avoid the mommy or daddy track at work, March 1^st should have a big red X in your calendar. To have a chance of getting your toddler admitted to kindergarten, you must have your enrollment application sent before this date. This year, which is the first time I’m trying to enroll my daughter, was the first year you could apply through the municipality’s web page. There is a shortage of kindergartens in Oslo, so parents flocked to the online application service only to be greeted with the error message below when sending their applications.

I don’t know any of the developers working for the municipality, but I reckon that they’re not toddler parents. If they had been they would have known that with the lack of kindergartens and the huge number of desperate parents trying to enroll their kids, a kindergarten application service needs proper load testing. The ASP.NET application scaled, but the kindergarten application service shows that a system isn’t more scalable than its weakest link. For the application in question it was the fact that an anti-denial of service filter blocked the service from sending application forms to a mail account.

Later this year Visual Studio Team System turns load testing of web applications into a breeze. Since all tests are mutually the same in Team System, you can use both web tests, unit tests and even manual tests when running load tests. I wouldn’t recommend manual load testing though, and I believe the case of the kindergarten application service goes to show that manual testing isn’t enough. Hopefully, the developers will learn to use these tools so that applying for kindergarten enrollment over the internet will be possible next year. Although I hope that I’ll get my daughter enrolled this year and hence won’t have to verify if the service is able to tackle the load next year.