VSLive! Speaker Interview — Martin L. Shoemaker

Why reinvent the wheel? VSTS, a whole new product for process support, takes what you’ve got and makes it better by integrating with and extending existing products. While it does provide new features in those existing products, it’s a truly a process improvement by design.
At VSLive! Orlando we’ve taken a close look at how VSTS can make your work—your life—easier. Resident expert on VSTS, Martin Shoemaker is covering several areas on this topic at the conference and has given us an insight into what VSTS can do to improve your processes today.

What are the new features in VSTS?

In a way, that’s the wrong question. That question sort of assumes that VSTS is a new version of something that came before, and it’s not. It does provide new features in existing products; but those new features are the spoonful of sugar that makes the medicine go down. Process improvement is the medicine, the real value in VSTS. So while I want to answer your question, I want to make sure we get into process after that.

Now to answer the question as you asked it, we really need to define two things: who is using the tool, and what tool are they using. There are new features for architects, developers, and testers, all using Visual Studio; and there are new features for project managers using Project or Excel. And then to support the process, there are new features for everyone via Team Explorer, which can be integrated into Visual Studio via the various VSTS editions. And of course, there are all the new features in Visual Studio itself, chief among them (from a process perspective) being the Class Modeler. So really, this is multiple questions.

For architects

Modeling. Modeling, modeling, and more modeling. Besides the Class Modeler, there are four new modelers in Visual Studio Team Edition for Software Architects.

The Application Designer lets you design reusable applications, services, and other sorts of components, as well as the interfaces and connections between them. Then you can select them and generate project shells that can be fleshed out via code and the Class Modeler.

The System Designer lets you design a system made up of reusable components from the Application Designer. Where App Designer is about possible ways to use and connect components, System Designer is about defining a specific way to connect them for a specific purpose. System Designer may seem redundant the first time you use it; but when you go to reconnect and reuse the same components in a different way, you’ll appreciate the different perspectives of App vs. System.

The Logical Datacenter Designer lets you model the optimal security zones and servers within those zones to support your System. Or at least, that’s the way I think of it, because I’m usually thinking in terms of new deployments in clean environments. The VSTS team calls this “green field” thinking, and it’s a luxury a lot of people just don’t have. A lot of people have to work within an existing datacenter structure, a structure owned by the datacenter administrators and a structure that the architects and developers cannot change (or at least not easily). So for these teams, the Logical Datacenter Designer serves a much more important purpose: documenting that existing structure in terms of zones and servers and the allowed connections between them, so that the architects know the constraints within which they must work.

And then the Deployment Designer lets you tie all the other work together. It lets you model the deployment of systems and components from the System Designer to Servers from the Logical Datacenter Designer and ask, “Do the connections between these components violate any of the constraints on connections between these servers? And if they do, what are we going to do about it?” Again, this can be especially important when designing for an existing, fixed datacenter, because “what are we going to do about it” can have repercussions back through all of the other modelers, including even the Class Modeler and the code itself.

For developers

Primarily code analysis. Visual Studio Team Edition for Software Developers adds four analysis tools, plus a testing tool.

First, there’s the Static Code Analyzer, which is like the old FxCop tool, but more powerful and more closely integrated into Visual Studio. It lets you check code for compliance with common standards, policies, and practices. So it helps you to recognize common missteps; but it also helps you to make your code more consistent with the .NET Framework code. Consistent code is more readable code; and more readable code is more maintainable code.

Next, there’s the Dynamic Code Analyzer. This tool allows a developer to test the run-time behavior of a component, including whether it overruns its memory and how it manages resources such as handles and critical sections.

And then there’s the Code Profiler. And as profilers go, this one has a ton of features. It will record which types and how many instances are created during a run. It will produce a hierarchical call tree. It will capture and record events from ASP.NET, IIS, and other providers. And it does sampling, instrumentation, and other performance measurement techniques.

And then there’s the Code Coverage tester, which will let you verify what parts of your code are executed during a run. This is important, of course, because code that never gets executed during testing is code where bugs can hide. Programmers get in the habit of running their apps the same way, over and over, and never executing other paths that may be perfectly natural for users to follow.

And finally, there’s Unit Testing. The VSTS Unit Testing tool provides powerful unit testing features comparable to NUnit or JUnit; but then it goes farther, providing a lot of support for automatically generating tests. Now those auto-generated tests don’t actually do anything. You still have to write the test code. But the test infrastructure is generated for you, along with some helpful comments to guide you in fleshing out the tests.

For testers

Well, they share some new features with the developers: Visual Studio Team Edition for Testers includes the Code Coverage and Unit Testing tools. After all, testing at that low-level code view is a shared concern for developers and testers. But beyond that, the tester edition adds three new tools.
First, there’s the Load Testing tool, which allows testers to test how an application performs under different types of load. It includes features such as Browser Impersonation, IP Switching, and Network Impersonation to simulate various network access scenarios. It will also trace the performance of SQL queries and record various Windows performance counters.
Next is the Manual Testing tool. The VSTS team recognized that you may have a large investment in existing manual tests. And more than just a monetary investment, those tests represent a knowledge investment: they capture things that you know about the proper behavior of the system. You can’t afford to lose those manual tests. So in keeping with their goal of augmenting the way you work, not changing it, they added support for gathering, documenting, and reporting the results of those manual tests in the same way as results from the Profiler, the Load Tester, and other test tools. You do the same testing work you always did, but the results are more accessible and visible.
And finally, there’s Test Case Management, which helps to organize and plan your tests, including individual test case data that allows you to run the same test procedures but with different cases to test different aspects of your system.

For project managers using Project or Excel

Well, the answer is the same for both: integrated work item list management. The techniques are a little different in the two tools, of course, but the core feature is the same.

A work item is some activity that has to take place as part of a development project. You might call them tasks, assignments, jobs, To Do items, whatever. In VSTS, they’re generically called work items, and they’re sort of the “atoms” of any development process in VSTS. Different teams will follow different processes for different projects, but every process will be defined by the work items performed and the resulting work products.

One very well-known work item management tool, of course, is Microsoft Project. It lets you define a plan for a project made up of work items (“tasks”, in Project) assigned to resources (people, teams, machines, facilities, etc.) and scheduled over time. VSTS plugs into Project and lets you pull task lists from the Team Server database, add them into a Project schedule, manipulate them, and update the Team Server. Now in my work, I don’t like the fields that are pulled into Project. I think that other fields should be pulled in as well. But the beauty of this add-in is that it’s very customizable, very easily. With a few simple clicks, I can pull in specific Team Server fields and map them to Project fields. So it lets the Project-using manager keep using that favorite tool, just with some added power.

But much as Microsoft would like to sell lots of copies of Project, it turns out that a far more common “project management tool” is task lists manually created and maintained in a matrix editing tool—in other words, Excel. A lot of projects are managed with columnar lists created and formatted in Excel, without all the powerful capabilities of Project. So the VSTS team decided to support that style of project management as well. Just as with Project, you can pull a task list from the Team Server database into Excel, customize the fields and column ordering, edit the tasks, add new tasks, and so on.

And in both Excel and Project, the VSTS add-ins will do error checking, so that your manually created entries fit properly within the Team Server schema. It’s really close to effortless process integration for these tools.

So how does VSTS change/impact/improve the software development processes?

I know I have a habit of answering a question with a question, but I can’t help myself: what is your software development process? For that matter, do you have a development process beyond “a bunch of people work really hard to make things happen”? For some teams, that may be the biggest change: VSTS may provide the opportunity and the tools and the power to implement a defined process.

But for teams who already have a defined process, the ideal answer is: “VSTS doesn’t change your process in any way. It just makes it easier to follow your process, by integrating the process into your development, architecture, testing, and management tools.” Now that’s the ideal, and it will only be true for two groups of people: people who build their own process, and people who are already following one of the two Microsoft Solutions Framework processes that ship with VSTS (or another VSTS process built by a third party, though there aren’t many of those yet). See, deep, deep under the hood, VSTS is a process-building toolkit, so that you can create process tools to support an existing process, and not change that process appreciably; but then it ships with the two MSF processes, and teams may decide that the simplest path is to use one of the MSF processes as is or with only minor customization. For those teams, the impact on their process could be pretty large, depending on how far MSF varies from their current process. I’ll explain MSF shortly; but first, I want to explain how VSTS defines a process, so that you can see how it can support your process.
In a sense, VSTS defines the “atoms” out of which processes are built; and then these atoms are assembled into different processes. The atoms are roles, workflows, work items, work item state transition rules, artifacts, artifact check-in rules, and guidance pages. Remember guidance pages, because they’ll have a large impact on the successful adoption of your process. They may be a big reason for teams to choose one of the MSF processes.

A role simply defines a role that one or more individuals fulfill as part of the process. A role is largely defined by its workflows: the large-scale jobs that a person in the role must fulfill. So for the role Architect, for instance, a workflow might be, “Design and verify the communication infrastructure.”

That’s too large to think of as one task, but it is one responsibility for an architect. In fact, I’m tempted to use the term “responsibility” as a way to explain workflow; but responsibility sounds kind of static, and workflow is dynamic.

In fact, a workflow is all about work items and work item states and how they change. It’s all about what sort of work items you’ll perform within the workflow. Now “work item” is a pretty vague term, and sometimes people wonder what it means exactly; but the simplest definition is just a task, a job that some team member must do as part of a workflow. In our “Design and verify the communication infrastructure” workflow, one work item might be “Estimate the volume of message traffic between users and the server.” That’s still a big job, but it’s a lot smaller than “Design and verify the communication infrastructure.” It’s a job you can imagine assigning to one individual, and expecting that individual to come back with an answer in some reasonable length of time. In other words, it’s a task. In MS Project, for example, a schedule is made up of tasks, and those are usually good examples of work items (although in Project, one task may be made up of multiple subtasks – VSTS work items can be related, but they can’t be aggregated like this).

And then the VSTS team made the situation just a hair more confusing by defining a Task within MSF as one category of work item. Thanks, guys, for overloading that term! But I’m picking on them to make a point: work items are grouped into categories. In MSF Agile, a Task is some job that needs to be done, but that doesn’t directly involve writing or maintaining code. Another category is Bug, which involves fixing defective code. And so on. Categories describe common rules for similar work items. And those common rules are mostly defined by States. Every category of work items defines one or more states. For a Bug, for example (and this is how I might define a process off the top of my head, not an exact description of MSF Agile), the states might be Open, Irreproducible, Reproduced, Investigating, Fixed, and Closed. But it’s not enough to just have states; we have to have transitions between states, rules that restrict those transitions, and actions that trigger the transitions. Otherwise, a Bug could be entered into the system immediately in the Closed state, meaning no one will bother to look at it. There’s one that’ll never get fixed! So in this example, I would say that a bug starts in the Open state.

From there, it can go to either Reproduced or Irreproducible; but this is where transition rules and actions come into play. We could have a rule that says, “Don’t allow a Bug to go to Irreproducible except when a tester files a test result that shows we couldn’t reproduce it.” And another rule, of course, would say, “Don’t allow a Bug to go to Reproduced except when a tester files a test result that shows how to reproduce it.” To continue this example, a Bug can go from Reproduced to Investigating when the tester produces a test case that reliably produces the Bug, from Investigating to Fixed when the developer changes the code so that the test case now passes, from Fixed back to Investigating if the tester finds that there’s still a case where the Bug pops up, or from Fixed to Closed when the tester confirms that the Bug is dead. The set of possible states and transitions define a lifecycle of a given work item type; and the activities that a given person performs related to a work item are part of that role’s workflow for that item.

Now there are two atoms that were implied in the scenario above, but not explicitly identified: artifacts and artifact check-in rules. An artifact in VSTS is any persistent piece of information generated as part of processing a work item. So that includes source code, design diagrams, test cases, test reports, you name it. If you want to save it, it’s an artifact. And when you save it, you’ll be saving it to a new source control system. Absolutely new, as in “No, this isn’t SourceSafe, it’s nothing at all like SourceSafe, please believe us!” Microsoft wants people to be very clear that this is a new source management system, built on SQL Server for power and robustness, and capable of archiving every sort of artifact, not just code files. And then tied to that are check-in rules; and the most valuable one, in my opinion, is, “Never let anyone check anything in without tying it back to a work item.” Now “never” is a little strong there. The VSTS team made this rule optional; and even when it’s in force, it’s still possible for users to override it (though they have to explain why).

Now does that sound like an awful lot to understand about processes in VSTS? Yep, because I’ve missed the most important part: the users don’t have to understand more than a tiny bit of how the process is built, because the tool understands it for them. All that the users have to understand is how to follow an assigned workflow, using familiar tools plus some new, not very complex forms; and the users can see all work items assigned to them as well as related information right inside of Visual Studio via the Team Explorer. All this stuff about the “atoms” of a process is important to someone who builds a process, because they have to know how to explain their process to VSTS; but if they do that job well, the VSTS users will be able to just naturally follow the process.

But a big part of doing that job well is that final atom I told you to keep in mind: guidance pages. The forms that a VSTS user sees as part of a workflow will ask some questions, but they won’t tell you how to answer them. That’s the goal for guidance pages: to explain the process well enough that VSTS users can learn it, follow it, and refresh their memories when they forget how it works. And good guidance pages will be the hallmark of a well-implemented VSTS process, because a process that users can’t understand is one that they’ll either get wrong or else skip all together.

And that brings me nearly full circle to the start of this answer: many teams will opt to just adopt one of the two MSF processes that ship with VSTS, or else to customize them in minor ways, rather than build a whole new process; and part of the reason they’ll do so is the very rich, very clear guidance pages that come with those processes. The VSTS team invested a lot of effort into those pages, making them very detailed and yet very comprehensible. They’re a guide, a reference, a tutorial, and more, all with some very polished graphics and prose. It will be hard for any team who builds their own process to match the MSF guidance pages for depth and clarity. In fact, I’ll make a bold assertion: if you’re not prepared to at least strive to match the MSF guidance pages, you might be better off not building your own process; because I’ll say again, a process that users can’t understand is one that they’ll either get wrong or else skip all together. The VSTS team provided two very good examples processes that users can understand.

So what are the two MSF processes in VSTS? They’re MSF Agile and MSF CMMI. As the name implies, MSF Agile is for teams that follow an Agile Design philosophy of smart people with minimal structure who respond to change by creating much of their process as they go along. There are only five work item types in MSF Agile: Tasks, Features, Quality of Service, Bugs, and Test. (That’s off the top of my head, so I may have gotten one wrong.) The number of roles and states is similarly small.
MSF CMMI, meanwhile, is aimed at teams striving for CMMI Level 3 development. It defines many more work item types, many more roles and states, and many more specific workflows.

How does Team System support the entire development team?

Each team member will work within a familiar tool, with different specialty features for Architects, Developers, and Testers; but then that tool will have an integrated Team Explorer that allows a user to find, work on, and update work items, as well as to get guidance on how to follow the process. And the Team Explorer will also allow team members to query and report the status of individual work items, along with analysis metrics that describe the overall status of the project. And the new source control engine will archive pretty much every persistent artifact of the process, and will tie particular check-ins to particular states of particular work items, so that there’s much more visibility into the status of the artifacts and the work on those artifacts.

What is the most significant advantage to implementing VSTS?

Communication. A recurring theme of all of my work for the past six years has been, “It’s all about communication.” As projects get larger and more ambitious, I believe that communication becomes a much more critical factor in project success than technology. All the technology in the world can’t make the wrong system into the right system, but better communication might prevent you from building the wrong system in the first place. And what I love about VSTS is how the system of work items and artifacts all tied into familiar tools helps turn those tools into communications channels. In the bad old days, a programmer would find out what code to work on by sitting in a long, boring meeting. A project manager would learn the status of that work by dragging the whole team into a longer, even more boring meeting. I hate that kind of meeting. Everyone hates that kind of meeting. Well, VSTS won’t eliminate every long, boring meeting; but in an awful lot of ways, it gives you communication without meetings. And that makes me a very happy programmer!

VSTS sessions and full-day workshops at VSLive! Orlando include

Visual Studio 2005 Team System: Advanced Testing Techniques to Improve the Quality of Your Applications
Five Management Essentials: Estimating, Scheduling, Planning, Tracking and Correction with VSTS
Requirements Patterns with VSTS
Best Practices for Testing and Debugging Managed Code: VS 2005 & VSTS
VSTS for Everyone: Best Practices for the Whole Team
Increase Your Predictability of Success with Team System

About Martin Shoemaker
Martin is a software developer with 20 years experience in the industry. He has worked in the fields of color science, on-line shopping, time-series databases, material handling, medical imaging, and customer relations management. He has twice been recognized by Microsoft Corporation as an MVP for Visual Development with C#. As an instructor and consultant for the Richard Hale Shaw Group, he offers his guidance and expertise to clients who need high-quality design services with UML, as well as custom software in the Windows and .NET environment. He’s obsessive about Object-Oriented Analysis and Design with UML, and he thinks you should be, too. You can reach him at Martin@TabletUML.com.