I think Visual Studio .NET is a pretty darn good IDE. Don't get me wrong, it has it's quirks (anyone else have to use TaskManager to 'Switch To' VS.NET when it becomes "stuck" in the task bar?) and idiosynchracies that I could do without. All in all, though, it has a lot of great features and is a very productive environment.

I really like Windows Server 2003 and IIS6. Windows 2003 seems to be a "lessons learned" operating system with a bunch of nice new features to boot. IIS 6 has a well architected process model with nice XML configuration and the whole nine yards.

So, they've got the development environment and the platform down pretty well. They are missing the boat BIGTIME though when it comes to rounding out the rest of the development lifecycle. Here are my beefs:

  1. Enterprise Servers - The pricing is very competitive and the features also stack up very well with the competition. Where is the developer connectivity on these products though? I mean, only 3 or 4 of the server products have managed APIs and those are definitely 1st gen APIs. Why does it appear that this was an afterthought to the .NET Framework, et al? It took over 6 months after the Framework was released before a server was .NET enabled. Even then, there doesn't seem to be any visual connectivity from VS.NET Ok, I shouldn't be too harsh because in the last six months they have released versions of Content Management Server, Commerce Server, and Sharepoint Server that have managed APIs. Those servers are definitely where the most of the development is being done (from what I have seen) in the market. The problem here is that I had a hard time selling the enterprise servers before these versions came out. The ONLY people I could get to buy in to the .NET enabled versions of these products were the hardcore Microsoft shops who would have bought them regardless.
  2. Source Control - Visual Sourcesafe 6.0xyz. Yeah, 'xyz' is the next super minor build that will be available next month. Ok, kidding aside, Sourcesafe needs to be seriously overhauled and/or replaced. I'll bet anyone $100 dollars that it is being replaced but it is WAY too late. Other products are propping up and I'm very tempted to buy them. Microsoft is lucky that I invested money in Sourcesafe and I don't want to have to reinvest. It's not a good thing when your source control product is probably considered the most unreliable product available in its space. It's especially disconcerting when your development products are used by millions of developers. I would argue that Visual Sourcesafe should be retired and a completely new product pushed. I don't trust Sourcesafe and I've used it for quite some time; I know new folks don't trust it because they only hear horror stories. Microsoft, PLEASE give us a more robust source control product.
  3. Build Process - Holy cow, Batman! Microsoft only has one answer for the build process and it was created by a consultant from a third party?! Not only did they not create the software but it didn't appear until almost a year after the first version of the .NET Framework rolled. I know they have an extensive build process for their software. Why, then, do they not see the need for all of us to use a build process. Wait....they do. It's in the prescriptive documents but they do not provide us with any tools to facilitate this process. Microsoft, PLEASE give us some build tools.
  4. Testing - Microsoft does all kinds of unit tests, smoke tests, and every other kind of test you can imagine on their software. I'm willing to bet that they have some pretty nice testing tools/software that have been built over the years. Microsoft, PLEASE share some of your expertise in testing with us. We can all write better software and have better tools if you would open up your bag of goodies for everyone to use.

Now, I know about NAnt, NUnit, Draco.NET, CruiseControl, and the various source control packages on the market. Some of them I use and some I don't. The problem with most of the open source tools is that there is generally little documentation (I don't mean docs for the API; I mean usage documentation) and most Microsoft developers don't have a clue about open source tools (what they are, where you can get them, etc.). Keep in mind that there are hundreds of thousands of applications being written by government agencies, small and medium private companies, and many more organizations who don't have the staff or the expertise to glue a bunch of open source packages into a cohesive process for developing, testing, and controling software.

I work with a lot of software development shops (both in training and consulting) and I can say with 110% confidence that these issues need to be addressed by Microsoft for two reasons:

  1. These processes are a crucial part of the SDLC. If they are not in your organization then they should be. I'd be willing to bet that if you are not incorporating things like source control, build process, or unit testing then it is because you a) don't have the expertise or b) it's too time consuming given the current tools available. Microsoft, make it easier for these folks and do a better job of pushing these tools/processes in front of their face.
  2. Microsoft needs to do a better job of pushing best practices with developers. They have started to improve on this with the Patterns and Practices books but that only addresses one group of people (those with knowledge to implement the suggestions and those with the time to build the custom processes to support the process). There is a huge gap in the SDLC of most Microsoft shops and it's is partly Micrsoft's fault.

Whew, I feel better now.