There are a couple of issues that come up for developers who work on Visual Studio that just aren't issues for most people. The first is that working on components of VS while using VS is hard. It's hard for a couple of reasons.
Before we started working on VS2008 we had a single solution for both of these problems: Side by Side installs of Visual Studio. Back in the day, most developers who worked on Visual Studio didn't actually install Visual Studio through the setup process.
Instead we had a batch script which would copy the binaries from the daily build machine and then run regsvr32 on a huge list of different dlls in order to getting a "working" version of VS. This had some advantages, but also some very serious drawbacks.
Because of the second drawback above, the division made a decision at the end of VS2005, that we wouldn't continue to use batch setup for VS2008. Instead, we invested in updating our setup technology to make it easier for developers to build setup, and to understand how the setup gets built, so that it became easier to keep setup working. We also invested in some tools to make using an installed build easier. For example, we wrote a tools called "pupdate" that is able to update installed binaries from the location that they are built to automatically.
However, we never did get to the point where it was possible to install two VS2008 builds side by side to enable the experience above. How did dev's adapt to this? There were 3 different ways:
None of these are quite ideal, it'd be really nice to go back to the old days of being able to install 2 builds of VS side by side. We're thinking about investing in that for VS10, but as far as I know, it's still up in the air.