Life at Microsoft and Customer Requests
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.