Redmond Developer News

Developer's Toolkit

Visual Studio's Future

Microsoft is attempting to address one of the biggest perennial problems with the application development process: communication among disparate roles in development.

• By Peter Varhol
• 11/01/2008

I had the opportunity recently to speak with Dave Mendlen, director of the Microsoft Developer Division marketing group, about the next version of Visual Studio. This version, recently announced as Visual Studio 2010 -- with no code name -- is still a long way from release. But the Visual Studio team has some specific concepts that it's building on as it once again raises the bar for dev tools and techniques.

With Visual Studio 2010 and accompanying Visual Studio Team System (VSTS) features, Microsoft is attempting to address one of the biggest perennial problems with the application development process: communication among disparate roles in development. This isn't about developer communication, which was one of the goals of VSTS. Rather, it's about making sure that the flow from design to development to test is more seamless.

Ways to Work Together
Microsoft is building in tools to enable various development roles to better work with other roles. This process starts with three editions of Visual Studio -- Architecture, Development and Test Editions. Something worth noting: Visual Studio Database Edition is going to be folded into the Development version.

The Architecture Edition incorporates the ability to define and enforce an application architecture. While I haven't yet seen this in action, what it purports to do is let an architect diagram the particulars of an architecture, and be able to place the classes that are being developed within the context of that architecture. Those diagrams can be at any level, from simply a separation of presentation, logic and data layers to complex components and interactions to those components.

Once the developer starts coding, the code being built can be matched against the architecture as defined by the architect. This can even be done as a part of the VSTS check-in process, so that code that doesn't match the architectural map can't be checked in.

In this way, the intent of the architect is clear and communicated to the development team in a way that can't easily be misunderstood or ignored. It can certainly be debated, and I expect to see a lot of give and take in teams that use this feature.

Between Testers and Developers
Perhaps the most interesting part of the communications process will be found in the Test Edition. One of the most common outcomes when a tester files a bug report is this response back from the developer: "Cannot reproduce. Bug closed."

Of course the response, "Works on my machine," has bedeviled testers for decades. Often the reason for the disconnect between dev and test is not that there's no real bug. And it's almost certainly not the case that the developer doesn't pursue the bug report rigorously. Rather, it can come down to differences in machine configuration, or more likely an incomplete or ambiguous description of the bug and how to replicate it.

The end result is a time-consuming back-and-forth between development and QA. This wastes time and effort that could be more fruitfully applied toward actually finding and fixing bugs. Microsoft's solution is to reduce the ambiguity of the bug report.

Enhanced Collaboration
Specifically, the Test Edition enables the tester to record a video of the keystrokes used to reproduce the bug, as well as showing the results of that bug -- similar to what you might do with a commercial tool such as Camtasia. The video can be attached to the bug report so that the development team can follow the exact steps needed for reproduction.

More telling, the bug report can also capture the "state" of the test machine during that process. That state file can also be a part of the bug report, and developers can use it to drive their debugger to see what's happening on the test computer while reproducing the bug.

"A .PDB file?" I asked, referring to the file generated in debug mode that matches the execution code with the source code.

No, more than a .PDB file, I was told. It actually captures the state of the running application and lets you transfer it into the Visual Studio debugger.

The upshot is that some of the biggest communication issues in software development may just become more manageable. Building software is about more than writing good code; it's also about making sure everyone else in the process is on the same page. Visual Studio 2010 promises to bring that ideal closer.

Reader Comments: