Microsoft is missing the SDLC boat….big time….

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.

Comments (14)

  1. Jesse Ezell says:

    Patience is a virtue. Microsoft is in the middle of transitioning a lot of its internal tools and making them available outside, so you will see a lot of cool stuff coming out the door in the next couple of years.

  2. Alex Lowe says:

    Yeah, I know they are working on rolling a lot of internal tools but I want to make sure that they hear the need loud and clear. If nothing else, it might give a PM some more ammo to get a neat feature into one of those tools. =)

  3. Scott Prugh says:

    I wholeheartedly agree.

    I think there are a few things you missed above:

    5) DB Source Control/Versioning Tools

    This is incredibly painful to do correctly. MSFT needs to step up here and provide a source control solution for sql server.

    6) Incident/Request tracking

    7) Packaging(is this part of automated build??)

    8) Patch deployment

    I would even go as far to say that I would like to see MSFT wrap Project Management tools around all these things(ala Project Server/Share Point) so that I can have a central dash-board where developers can go to see what they should be doing and when….

    I have found MSFT’s leadership in the areas above disappointing.

    You can find third party tools on the market that do some of these things but it is difficult and time consuming to build a holistic end-to-end process. You have to write a lot of your own band-aid tools to get the process even close to automated.

    Laying out the entire plan and building the correct processes and infrastructure for these things is hard. It is extremely difficult to write and piece together all the tools from planning to patch deployment that need to be in place when you scale up a software shop. With 5 developers this stuff is easy to manage ad-hoc. With 100’s across diverse locations this becomes a huge task. This is the un-fun piece of software development and much more difficult that any technical challenge most teams/developers will ever come across. The software is generally the easy part. The process, logistics and communication is hard.

    Seeing that MSFT seems to do all this stuff pretty well, they need to step up here. They have the money to spend on R&D and tools to perfect these processes. Most shops need a process that works and cannot spend the time/money to automate their processes. They need to focus on their product….

    We see glimp

  4. Alex Lowe says:

    Awesome comments Scott! I definitely missed a bunch of those points (although I think I was subconsciously thinking of them when writing my post).

    Bug tracking is a great one and the database versioning is insane right now. Try automating the build process when you have a database that changes even every once in a while (especially if it is lookup tables with data that also needs to pushed) – YUCK!

  5. Jon Galloway says:

    The delay in the VSS release is probably tied to the WinFS release, but it is extremely painful. The company I work at switched to StarBase, which I’m having some trouble getting used to.

    As you mentioned, there are third party tools that cover most of these areas, but evaluating, configuring, connecting and learning them all is a huge distraction from writing software. Most MS focused developers use MS products because they want consistency and productivity, and moving between a bunch of disconnected, dissimilar applications does not support the process.

    To look at the tools MS sells, you’d have no idea how well they’ve thought throught the development process (the MSF, the great stuff the practices group has been putting out lately, the fact that they’ve successfully managed millions of lines of code through the cycle successfully…).

  6. Michael Dorfman says:

    I agree with Alex’s original list, and Scott’s amendments. One note, though: a solution for #8, Patch Deployment is forthcoming. There’s a "BlueBrick" (Application Block) for Update Management that is in beta at the moment, in BlueBrick Beta GotDotNet workspaces.

  7. stefan demetz says:

    how about a VS.NET "development server"?

    with docs, build tools, debugging, automatic unit/load/stress testing, SCM ….

  8. Alex Lowe says:

    Thank you for the link. I’m well aware of the Application Blocks (and I really like them) and some of the work that the Prescriptive Architecture Group (PAG) and the Patterns & Practices teams are doing. I still believe there is room for some more commercial applications to help complete the SDLC however.

  9. Yeah I agree. I’d even pay for a SDC solution that:

    * Uses NAnt

    * Runs as a service/client model where the server contains the workflows and accessible tools to change them from the client. Workflows are split into: builds and deployment and has knowledge of different runtime environments (development, acceptance and integration testing and runtime env.)

    * Workflows have role-based security model defining who can run or edit them (for example only administrator can run the workflow that deploys the project to the real runtime environment).

    * Server logs everything (changes, builds etc.)

    And much more, wrapped up in an easy to use solution.

    I’ve been looking at CC.NET, Hippo.NET, Draco.NET, CCA and others but I’m not happy with any of them. Some are incomplete as to the vision I want and the only one that comes close and caters to enterprise needs is CCA and that hasn’t even been updated for months, the main page with the docs on sourceforge went down some weeks ago 🙁 (

    I’ve thought of building such a solution myself but I don’t have the time to bring it up to the level I need 🙁

Skip to main content