Redmond Developer News

Developer's Toolkit

Jazzing up Dev Teams

We don’t use a hammer on a daily basis just to make sure all nails are still fully pounded in, and we don’t use development tools if we don’t think there’s a problem.

• By Peter Varhol
• 07/01/2008

Eight years ago, at the turn of the century, when I was building development tools, one of the big frustrations was that it was impossible to convince enterprise development teams to use such tools as a part of their regular process. Tools use was almost always an exception rather than a rule. If you had a memory leak in unmanaged code, you turned to a leak detector like BoundsChecker. If you had slow code, you started the performance analyzer. But few teams built in regular tools use as a standard part of their development process.

Fundamentally, that's how we use tools of all types. We don't use a hammer on a daily basis just to make sure all nails are still fully pounded in, and we don't use development tools if we don't think there's a problem. We never did figure out how to get tools used consistently in the development process, despite all the propaganda we produced on how it was good for you.

But today Microsoft has seemingly figured it out. Visual Studio Team System (VSTS) addresses the use of tools as a part of the application process by providing a platform for integrating those tools into a larger configuration and build-management framework. In addition to incorporating some of Microsoft's own tools, such as static analyzer FxCop, VSTS has an integration API that lets third-party tools integrate into its framework.

S. "Soma" Somasegar, Microsoft senior VP of the Developer Division, told me over a year ago that 65 percent of Visual Studio users were also Team System users. That percentage seems excessive -- it likely included the Team Foundation Server that's part of every MSDN subscription -- but there's no doubting that the Team System framework is an essential harness for tools to improve software quality and accelerate development. You can use it for source code and configuration management, communication among team members and, yes, plugging in your own set of developer tools.

Not the Only Choice
This framework doesn't even have to be Team System, however. IBM Rational's Jazz -- introduced in the spring of 2007, with the first components shipping this summer and the rest slated to roll out by year's end -- provides a similar platform for teams to use as a centerpiece of their dev efforts. While based on Java and the Eclipse rich client, the underlying technology matters less than its ability to enable .NET development teams to use lifecycle tools. The Eclipse platform is especially good at integration; its use of the OSGi -- formerly the Open Systems Gateway initiative -- makes it easy to plug in new tools and components and have them work seamlessly with the platform as a whole.

Both of these platforms have a common failing, however. VSTS incorporates the architecture, design, development, database development and testing versions of Visual Studio, in effect tying together all the versions of Visual Studio. Rational Jazz includes platforms and interfaces that enable interoperability with Rational ClearCase, ClearQuest, Build Forge and Subversion change-management products.

This is good insofar as it goes. Both platforms assume that all participants in a development team are technical and are doing something related to code. The Visual Studio integrations encompass the technical members of the development team, but fail to address others. At least Rational Jazz acknowledges that there's more to a development team than Visual Studio users, even if it doesn't yet have a good answer for integrating the rest of the team into the process.

Uniting the Team
These other team members play important roles in the software development process, but they are unlikely to use either Visual Studio or the Rational products in their daily work. For example, most dev teams include project managers, technical writers, configuration specialists, product managers and marketers, and perhaps even others who do the necessary work to contribute to the business and market success of an application.

How do you serve these team members? They don't need access to the source code, but they often need to download and install builds, post documents, contribute to schedules and discuss ideas among the team. There are tools that already make these types of interactions possible, but they're not yet integrated into VSTS or Jazz.

There may be some moves afoot, however, to correct this imbalance. I can't say more at this time, but look for announcements in the upcoming months that will help bring non-technical users into the development process by utilizing either VSTS or Jazz. If platforms such as Jazz and VSTS manage to integrate all participants in the development process, it almost makes me want to go back into the developer tools business once again.

Reader Comments: