Kirk Evans Blog

.NET From a Markup Perspective

Life at Microsoft and Customer Requests

@kaevans

Life at Microsoft and Customer Requests

  • Comments 2

Christopher Bowen's post on the Tools Affected by Visual Studio 2005 / Team System was extremely timely for me as it helped me gain perspective on Microsoft as a company that provides products to enterprise customers.

Just today, I cobbled together a rather lengthy response to a customer request on best practices for developing with Visual Studio .NET 2003.  I could point them to the Patterns and Practices book, “Team Development with Visual Studio .NET and Visual Source Safe”, but I knew that the customer wanted more meat on the bones.  They wanted to know about integrating unit testing, builds, and deployment to a QA environment and the common tools people are using to achieve this.  Most importantly, they wanted to know about VSS versioning and qualifying a labeled QA environment for production.  That implies a bit beyond the capabilities of a single existing tool such as BuildIt, which likely entails the convergence of several tools and approaches, possibly including a combination of BuildIt, NUnit, NAnt, XCOPY, setup and deployment projects, maybe even WiX.  The mention alone of 3 or more technologies to a single customer is daunting to deliver, and 10 times worse to hear from a manager who is seeking to simplify the development environment to make the team's developers more productive.  There were gaps in previous versions of Visual Studio and those gaps were comfortably filled by the list of products on Christopher's list.  Rest assured that people will find gaps to fill in future versions of Visual Studio as well.

I honestly had just accepted the array of tools on my desktop as the norm until a customer asked about Microsoft's plans for providing support for NUnit and NUnit AddIn for VS.NET 2003.  The question caught me off guard: these aren't Microsoft's products, so why should Microsoft be expected to support them?  I decided to ask that question and see what the customer responded with.  The response was as I had expected, but I hadn't considered the customer's reasoning:  “Well, then who do we contact for support?“  In a large enterprise focused on delivering consistent results through a vast number of supported systems, many customers absolutely subscribe to the concept of  “one throat to choke.“  If software fails for some reason, they don't have the time to go spelunking through Reflector to find the bug for themselves... that's why they have Enterprise Agreements and Software Assurance. 

Simply letting developers use whatever tools necessary to get the job done is not an option because this newly introduced software may have unintended effects on the product being introduced into the enterprise catalog.  What if you have a build of a community app that includes a virus?  Someone needs to verify the tool, verify there is no spyware or unintended consequences for a developer tool.  And if a tool is useful to one group, other groups should also be aware of it and have the resources to obtain the tool... which means the tool must be versioned locally and versions synchronized with the “free“ version. 

Without the single throat to choke, the enterprise hangs its hopes on a developer outside the organization that has a full time job as an independent contractor and works on a GotDotNet Workspaces project in his free time.  Even if these problems seem moot based on technical merits, think about the potential impact of involving legal teams in the monotony and minutae of licensing agreements.  Even if the dev team gets past their reluctant manager, past their internal standards committee, and past the legal department, they now have to repeat the process every time a fix, patch, or version upgrade is released.  I can see now why many companies simply say “no”, even if the cost of the software in question is free. 

Shocking as it may be for many of us (I have only been at Microsoft a short while, and have been an independent consultant and contractor for 10+ years) to conceive, there are many companies that restrict the installs to a desktop per coroporate policy... blog readers are not part of the corporate Standard Operating Environment, and you are unlikely to get a variance simply because you really think Don Box is cool.  In fact, many companies restrict (gasp!) the web sites that you are allowed to visit.  I use blog readers here as the example because you are likely using one... now stretch your mind to include other free tools like NAnt or NUnit, and you can see how the pointy-haired bosses might take offense at the introduction of some benevolent free application into their pristine environment.

I can easily argue against the viewpoint of the Iron Curtain Desktop Enforcement Department, and certainly would argue it daily were I a member of a team that was technically oppressed due to some seemingly overreaching policy that increased the amount of time it took me to develop software and possibly decreased my ability to ensure quality before the code goes to QA.  But while forming that argument, it becomes more apparent how the Iron Curtain Enforcement Department's policies make some modicum of sense.  Customers are asking for an integrated tool set along with the ability to integrate the tools in Christopher's list with VS.NET simply because doing so will make their corporate lives that much easier.

That said, it is personally going to be rough to unlearn the set of keystrokes that already seems embedded in my mind for XML development.

  • Hi Kirk,

    an excellent piece and highlights the enormous problems of working in a corporate environment. The problem is that the gaps in the tools have to be filled by something. Quite a few people, me included are finding that the TDD approach really helps in developing software. Which means that I now I use Nunit + a number of other open source tools to fill the gap. We do a small amount of development which means the risks are not so high. If something breaks it is my problem. In a larger company it becomes problematic, however, it is important to realise that the individual teams may still be small. Their easiest route to get a new tool is if it is integrated into their existing tool.

    This is the reason why I am saddened that it is seems like the Visual Studio Team System is an all or nothing approach and will be sold at a premium price. By all or nothing approach, I mean you take all the tools or none of them. I think some of these tools should be available in lower cost versions of Visual Studio.
  • > By all or nothing approach, I mean you
    > take all the tools or none of them.

    I think it is still a bit early in the cycle to make that call. One of the core concepts that has made Visual Studio .NET such a successful tool is its extensibility. While you might get all of the tools in Visual Studio 2005, I would wager that Visual Studio Industry Partner (VSIP) program will be leveraged in interesting ways to provide new functionality to Whitehorse and the rest of Visual Studio Team Services.

    I don't think Visual Studio will be able to stand as an island of complete functionality, that has never been a successful approach for tools. I don't think the people writing the tools are designing it to be an island, either. Indeed, this is Microsoft's first public forray into several of these tools, and they have traditionally designed to accomodate integration with partner tools rather than fail in isolation. Let's hope that history repeats itself here in a positive fashion.
Page 1 of 1 (2 items)
Leave a Comment
  • Please add 5 and 5 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives