An interview with Visual Studio Team System expert and Microsoft Team System MVP Richard Hundhausen.

May 16, 2006
URL:http://www.drdobbs.com/windows/vsts-in-the-wild/187203550

Scott Swigart recently sat down with Richard Hundhausen to talk about how Visual Studio 2005 Team System is being used in the real world. As a principal of Accentient (www.accentient.com), Richard has provided extensive consulting and training to companies seeking to implement Team System. Richard is also one of the few Microsoft Team System MVPs, and author of Working with Microsoft Visual Studio 2005 Team System (Microsoft Press, 2005).

DDJ: Richard, I'd like to start off by talking about some of the modeling features in Visual Studio 2005 Team System, and how you're seeing those being put into practice. Then I'd like to expand the conversation to talk about Team System at a higher level, and what features across the Team Suite software shops are latching on to, or panning. To get started, clarify a term for me: When I hear people talk about "domain-specific languages," what does that mean?

RH: Let me contrast that question with UML, the Unified Modeling Language. The industry loves it, and it's been around for a long time, but it's very generic at describing software interaction and flow. It's not specific to .NET. Some people would argue that it's getting more specific to Java, but I digress. "Domain specific" means that you pick a domain, and for you and [me] we're talking about .NET, and then you come up with a language that precisely describes that domain. It's still a modeling language, you're still dragging and dropping shapes and connecting them, and you can print it out and hang it on the wall, and feel all proud about it. But at the end of the day, it has domain-specific functionality—meaning it can generate .NET code. Or, it can generate SQL Server DDL script, or something like that.

DDJ: In other words, it might know about attributes, which are a .NET Framework-specific thing.

RH: Right, or something like "delegates" [www.sellsbrothers.com/writing/default.aspx?content=delegates.htm]. That's exactly it. UML's great, but have you ever used it to precisely define something that should be implemented in code as a delegate?

DDJ: So doing round-tripping, where you go from your diagram, to your code, and back to your diagram, that's much easier with domain-specific languages?

RH: Exactly. There's a DSL toolkit that lets you build your own domain-specific language. The example I use is, "Let's say you're Subway Sandwiches. You have Visual Studio, which is just a shell. Inside of Visual Studio you could create a DSL that would let you drag-and-drop meat, cheese, and so on, from the toolbox onto a sort of virtual sandwich designer. When you're done, you right-click and say, 'Go,' or, 'Run,' or whatever. It cranks out calories, a receipt, assembly instructions, and the like."

DDJ: Things like cost of goods.

RH: Right, inventory, anything. It's a language for designing deli sandwiches. That's what DSL stands for—"Deli Sandwich Language."

DDJ: (laughs) Obviously, when they built Visual Studio Team System, they built it for the express purpose of building .NET applications. Are the tools generic enough that anyone would actually use it for making a "Deli Sandwich Language?"

RH: Think of it this way: Visual Studio Team System is a domain-specific language for doing precise .NET development. By Team System, I'm talking about the "Visual Studio 2005 Team Edition for Software Architects." It's those codename Whitehorse modelers we've been playing with for a while now. Those are DSLs for doing precise .NET development, precise datacenter development, precise deployment diagrams, and the like. DSLs also have the ability to validate against rules. The other side of this is the whole SDM, or System Definition Models [msdn2.microsoft.com/en-us/library/ms181772.aspx]. When you're building these models, they're actually saved in an intelligent format, with an XSD describing what is and what isn't allowed in the files. You can take it to the next level and actually validate SDMs against other SDMs.

DDJ: So talk a little more about System Definition Models.

RH: If you open up Team System, and you say, "I want to create a new application diagram," and you start dropping web services on the designer, the little application designer file that you're saving is just a mess of hideous XML. That's actually an SDM document. There's a full-blown SDM specification. There's an SDM SDK that you can download. They're not just pretty pictures. There's actually intelligence in there, and they can perform validation and be transformed into other, more tangible artifacts.

DDJ: So what are the kinds of pretty pictures that you can make with VSTS? There are obviously class diagrams, but what other diagrams are supported?

RH: First of all, the class designer is technically not part of Team System. It's found in the professional edition of Visual Studio, but it is arguably a DSL. It turns pretty pictures into .NET code, and back again.

As far as Team System goes, there are four distributed system designers. The way I like to go through them is to start with the Logical Datacenter Designer. This is where an infrastructure architect would model the deployment environment, whether it's going to be deployed to a single box in the garage, or a whole rack of servers and domains and firewalls in a big datacenter somewhere. But, it's logical, and that throws a lot of people. You're not putting down ports and firewalls, and routers and hubs. You're using logical concepts like servers, zones, endpoints, and communication pathways.

The second designer would be for the application architect, using the Application Designer (AD). This is what people walk up to the whiteboard and do. They draw five squares, the first two are clients, the next two are web services, and the last one is a database. They connect them with arrows, make them different colors, and the like. This is your standard designer for connected systems. They can be Windows clients, web clients, and web services. There are some prototypes for BizTalk, Office, or other generic applications. There are more prototypes coming and the SDK allows you to customize as well. You can also get a Microsoft Operation Manager prototype. This is probably the most popular of the modeling tools.

Then you can compose those applications into systems. Maybe you have three web services running on three separate servers, and this comprises the proverbial "stock ticker" system. With the Distributed System Designer, you can lasso those three web services, give them a friendly name, and give them settings and constraints at a higher level. And then you can talk about deploying the system, even though it's composed of three applications. This is sort of the stealth designer—it's not one that everyone uses, but it's very important when modeling composable systems.

DDJ: This system designer isn't where you're architecting the internal details, but you're aggregating applications into larger units. What about deployment? How do you verify that your deployment is going to work?

RH: That's the last designer, which is the Deployment Designer. You bring up your systems on the left, and by systems, I mean applications, web services, databases, things like that. And then you bind them to servers. You might drag and drop your two web applications onto a server called "Zeus," where Zeus is your public Internet box. Then you might grab five web services and drop them onto a server called "Apollo." Maybe Apollo is inside of your firewall. And then drag and drop your database onto a SQL Server named "Pudding." If you ever try to drop something onto a server, and you get the "no smoking" icon, it means that it's not valid to bind that application to that server because of rules that you've set up in those SDM documents. The rules might say, "You told me that this server doesn't allow HTTP access, so you can't put a web application here."

DDJ: Does it give you good information about why you can't drag-and-drop, or does it just say, "No!" and you have to figure out why?

RH: There are two feedback mechanisms here: One is immediate, which is you just can't drop something on a server because you've got a pathway error, or endpoint error, on one of the diagrams. But if you get everything bound, then you can right-click and validate the diagram. This is where it does deeper analysis of the diagram. It makes sure that the settings of one mesh with the constraints of the other. Some of the messages that you get here are pretty deep and technical, and may require changes to one or both of the models.

Let me back up here and say that in my travels, and probably yours, you come across shops where software is king, and they will model and mold the datacenter around it. The budget is such that they'll buy the servers that are needed, they'll open up the ports that are needed, and so on. In that case, the Application Designer will win over the Logical Datacenter Designer. But I've also been in environments, such as many government agencies, where the statement is, "Here's the datacenter. It's not going to change. Deal with it." You might not be able to use the most cutting-edge versions of things. The application will have to mold to the datacenter.

DDJ: But the whole idea is to figure that out before you deploy. You're able to figure it out proactively that there will be a problem, instead of reacting to something that doesn't work.

RH: Hopefully months, if not a year in advance, you're finding deployment problems, even before the software development has begun. That's a lot different than a situation where it's 9:00am, and I've got guys standing here with briefcases and CDs ready to install, and it's not going to work.

DDJ: Is there any automated way to figure out what the constraints on a server are, or do you just have to somehow know that information and key it into your diagram?

RH: Great question. In Version 1 of Team System, it can autodetect Internet Information Server settings, and that's about it. I think SQL Server settings and Operations Manager settings would be some obvious things. In v2 and v3, I'm sure you'll see support for more servers, but this requires the other Microsoft product groups, and even Microsoft partners, to buy into the philosophy of DSI.

DDJ: So what's DSI?

RH: It's "Dynamic Systems Initiative" [www.microsoft.com/windowsserversystem/ dsi/getstarted.mspx]. You can have PhDs rattle on all morning long about what it is, and you still won't have an answer. For my 100-level explanation, I'd say that DSI is a way for product groups to create schemas for software. "Here's a schema, in the SDM document format, which describes the settings that are important for other software that interacts with this piece of software, as well as this software's constraints." Pick some server software, like Exchange. Now come up with a document that follows the SDM format, so it has a preamble section, metadata, and so on. The document describes all the possible server settings and requirements to run. That's a big initiative to build a specification that can handle so many pieces of software out there.

That's where we're going. Someday, we should be able to use these domain-specific tools to deploy bread to toasters. So Wonder Bread and Sears have to get together and come up with a common specification.

DDJ: Right, or at least in the short term, maybe there'd be designer support for Sharepoint, Exchange, Biztalk...

RH: Oh, you're thinking so small Scott! I'm seeing people who are saying, "Team System is a great proof-of-concept, but we want to build our own domain-specific things." I think the combination of Windows Workflow Foundation, which is already in late beta, and process-modeling solutions built using DSL Tools has a lot of people excited. People want to have a toolbox that has things in it like work orders, decisions, trucks, maintenance records, whatever. By back-ending those models with software factories, XML, code, or both can be generated and transformed. There are no boundaries to what can be created. Microsoft has never had a modeling framework like this before. It's exciting.

DDJ: Let's pull back a minute and look at all of Team System. You work with a lot of people, and it's been out long enough that some things are probably starting to emerge as front runners as far as the overall Team System feature set. Why are people buying this product? What are the killer features? Is it things like unit testing, code coverage, and so on?

RH: So, the people that are interested in the unit testing, code analysis, code coverage, and build, those are what I call the "N" people (people using NUnit, NAnt, and the like), and they're not gaining a ton of new functionality; but they are getting it all integrated into their daily IDE.

DDJ: How big of a deal is the integration? Are you finding people saying, "Now that it's in Team System, we're dumping all the Ns"? Or, is it more an issue that they already have the Ns up and running, and Team System is really going to have to prove itself to get them to move?

RH: It's both. If I'm talking to a room full of self-employed types like you and me, I get a response of, "If I want Team System, I have to pay extra for MSDN. I already have the Ns, etc. I don't need it just because it's Microsoft." But, if I'm talking to a law firm, or aerospace company, or insurance company, they say, "Yeah, the Ns were always out there, but we never really used them that much. Our company wouldn't have authorized it because it's some unsupported SourceForge thing." Now that it's integrated and supported by Microsoft, those people are raising an eyebrow, and they are really interested in it. There are also migration tools available to get people off of the Ns. We list quite a few on our widgets on our site [www.accentient.com].

DDJ: What I'm running into, with some of the smaller shops that I work with, is they don't have formalized testing. To some degree, the testers are the customers. This is shockingly common. So when I show them the unit testing, they're not really interested in going down a whole Test-Driven Development (TDD) route, but they are very interested in using it to sort of "smoke test" their application—maybe build a test that runs through a series of operations, and then look for a certain result in the database, or a certain output.

They might also be looking at it to test some of their algorithms, especially if they're planning on making some big performance optimization and they want to ensure that they don't break something. With some of these algorithms, it wouldn't be immediately obvious if the wrong numbers started popping out. If you run a histogram algorithm, for example, it's hard to just look at the data and know that it's right, so they see the importance of having a test suite before they start making big changes. To them, testing is now within reach, and maybe it wasn't with the Ns. Maybe Team System will lower the barrier to entry for automated testing, more than it will capture the top end of the TDD market.

RH: I think that's true. It's right there. It's just a right-click away. There aren't a lot of excuses for not using it.

DDJ: So when you look at all of Team System, what are the main reasons people are interested?

RH: My observations are: Number one is that it's the next version. They have an enterprise agreement, it's where Microsoft is going, so they're going to upgrade just because it's their policy to stay current. Number two is source control. They aren't satisfied with SourceSafe. They've seen demos of Team System and they know it can do very sophisticated branching, merging, and shelving, and they need better protection of their code. They need to have an enterprise source control system. That's what Team Foundation Server is being targeted at.

DDJ: Is it more of a concurrent source control, where there isn't really a check-in, check-out? In other words, is it more like CVS, where you aren't locking files when you're working on them?

RH: There are a couple of different modes that you can run it in. You can have a check-in/check-out mode where no one else can touch a file while you have it checked out. You can also allow other users to check-out, but not while you have it checked out. The default is a multiuser mode where everyone can modify the same files at the same time. It will try to automatically merge changes, or if there are conflicts, the second person checking in is presented with a three-way conflict resolver. It's a nice tool.

There have always been differencing engines, but this is a good tool where you can say, "I want these changes. I want those changes. I want to comment this. I want to shelve it. I need to throw a work item in here." If you'd rather not use Microsoft's compare and/or merge tools, you can link up your favorite tool instead.

The ability to associate things with work items is huge. You can say, "I'm going to check in 15 files. I'm going to put a comment across the whole changeset. And, I'm going to associate this change with two bug work items and one feature work item." That's pretty darn cool from a project-management standpoint. It really lets a project manager say, "What did my developers do all day?"

DDJ: Another impression that I get is that the work items are core to the product. Are you seeing the work items as being a driver?

RH: I've definitely met customers who say, "We're just getting it for the source control."

But then, once they have it in their shop, they start to see, "Hey, I can just right-click on this and create a work item." I think that feature will grow on people. Maybe they'll just do tasks at first, and then get into logging bugs and other types.

I've actually gone in and delivered training on Team System to companies that don't produce software. Seriously, all they do is crank out work orders, jobs, and job steps. They just want the portal aspect; they want the Team Project aspect. What they really like is that they can customize the methodology templates. You can take something like the MSF 4.0 Agile template, copy and paste, and customize it. You can put your logos in the corner of the guidance pages. You can put in your step-by-step definitions of a task. You can put your reports in. You can put your document templates in. You can create your own work item types, so instead of a bug and a task, you have a work order and a job. You compile that and upload it and, boom, you have your own custom process.

That's really the undiscovered country of Team System. If people will just take the time to document what they do, for projects of any kind, whether it's making sandwiches or generating work orders, or even writing code, you can put together a methodology template, and the portal will reflect it. The reports will report on it in real time. You can plug in your own domain-specific designer with your own toolbox. Then you can just scale it up from there.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.