Size of Visual Studio


 Ever wonder how large Visual Studio is? This public comment from the MSDN feedback gives some good stats:


Visual Studio is over 43 million lines of code, there are over 30 teams working on different pieces, with roughly 700 developers checking-in code to 11 different virtual build labs that are then integrated on a rotating schedule producing over 100 different builds of the product daily. In addition we have interdependencies with SQL and MSDN. When we ship an official release like a Beta or RTM (release to market) we lock down and are code complete several months before the actual release date to allow for a final test pass, to stabilize and hit stress goals, then get the best bits to fulfillment for mass production of media. Before code complete there is a long list of exit criteria for the product that must be met, ensuring all key features and scenarios meet expectations. We have customer bug exit criteria to ensure high priority issues are fixed.


We’ve had a very interesting challenge scaling development and testing techniques up to a product of that size. It seems like most methodologies (“You just write unit tests for everything and then you have no bugs”) I hear about are really intended for about 5 person teams. If you had a unit test for every 10 lines of code, that’s 4 million unit tests. That’s would be a lot of unit tests to run before a single check-in.  

Comments (21)

  1. Hasani says:

    I can only imagine what the situation is like for longhorn.

  2. Really interesting statistics on the size of Visual Studio 2005 by Mike Stall.

    Visual Studio…

  3. Tony Chow says:

    Are you saying that Microsoft developers do not unit test, Mike?

    Most clear-headed people would agree that unit testing is but one part of any quality assurance strategy, whether the team has 5 or 100 developers. I’ve yet to see anyone argue, however, that unit testing should be displaced once a project gets to a certain size.

    I’m very interested to hear how testing is done for a major Microsoft product.

  4. Impressive !

    Do you have any more detailed information about the scaling and testing difficulties ?

    Thanks,

    Bart

  5. Tony – No, I’m not saying that. We definitely unit test. I’m just saying that unit test strategies for a 5 person team don’t scale to 700 developer team. It’s impossible to run *all* the tests before *every* single check-in.

    Testing is a major challenge opportunity for a project of this size. Testing a product like Visual Studio (and the CLR) is a lot more than just having somebody sit in front of the product and clicking buttons. There’s an entire complex test stragety and we have a lot of talent in our testing infrastructure.

    For example, MDbg (an extremely extensible managed debugger written in C#) was originally done by our testing team as a way of testing the debugging services APIs (ICorDebug).

    This whole area is great blog fodder. Stay tuned…

  6. akraus1 says:

    Do the 100 builds daily mean a full or incremental build. I guess a full build will take a lot longer until it is finished. When you change some central library which is referenced by many others targets a full build would be the only thing to go or do you have some smart strategies to work around such things?

  7. Akraus1 – I don’t know for certain. There’s a whole team just running the builds.

    Many of them are indeed full builds. Others do full builds of part of the tree and piece that together with binary drops from other parts of the tree.

    We generally avoid incremental builds for official daily builds:

    a) there’s enough daily churn that an incremental build likely degenerates into a full build.

    b) incremental builds have a higher risk of an error in the build infrastructure. (eg, bad dependency anaylsis resulting in something not gettint rebuilt)

  8. just something about testing of Visual Studio.

    Have a read of my latest post, there is a link that will tell you how many testers there are, and how MS tests.

    It will even tell you wich software is used for bugtracking etc.

    http://bloggingabout.net/blogs/wellink/archive/2005/08/24/9068.aspx

  9. James Hancock says:

    That explains why it’s so damn slow and VS.net 2003 crashes so much….

    I’ve said it many times since Vs.net 2002 came out: MS has failed until the Win Forms designer is as fast as Visual Basic 6 was. But I still have windows that take 20 seconds just to display in the Windows Forms designer, and selecting a bunch of controls and CTRL + Arrow nudging still performs (in Vs.net 2005!) at about 20% real time as opposed to Visual Basic 6 that was instant.

    When an application gets to 30 million lines of code, it’s time to go and refactor and re-write most of it and clean stuff up because there isn’t 30 million lines of code of functionality in Vs.net. Sorry.

  10. At this point, I’ve got what seems to be an endlessly long list of things I’d like to eventually blog…

  11. Hoplog says:

    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.

  12. Hoplog says:

    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.

  13. Hoplog says:

    Visual Studio to duży i skomplikowany produkt. Na łamach swojego bloga Mike Stall przytacza kilka liczb, które pomagają to sobie uświadomić.

  14. Visual Studio is over 43 milion of code , 30 teams are working on it and … Read more I enjoy this

  15. Work at home moms. Wahm com the online magazine for work at home moms.