Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Visual Studio 2005: Unstable and Highly Recommended


Decoupling the Tools

DDJ: Rocky, one thing that you touched on was that you'd like to see the tools decoupled from the Framework so that they could rev independently.
Rocky: I don't think it's healthy for the platform to change radically and often the way it's been changing.

DDJ: What about other dependencies. If Visual Studio 2005 didn't ship, then SQL Server 2005wouldn't ship, and Team System wouldn't ship. There's a log jam of Microsoft products backed up behind Visual Studio 2005. The dependencies don't just go up the stack from the Framework to the development tools, but also across some really large products. What are your thoughts about the number of things dependent on Visual Studio 2005, and version 2.0 of the .NET Framework. Does that make the problem worse?
Bill V.: Dependencies have always been an issue, and it's a growing issue. The operating system will be dependent on the Framework. Office will be more dependent on the Framework. As these other teams want change, it just makes things far more complex than it used to be.
Rocky: I agree with Bill, and yet I honestly think that it has the potential for an upside. One problem that we often face is that Microsoft often tends to hire a lot of young, smart people, who have never worked in business. They've never worked in IT. They build compilers, and they build tools, and I think they generally do a wonderful job, but they really don't have any idea what it's like for us. We build stuff that's always dependent on Windows, .NET, and SQL Server. By definition, all the stuff that we build, whether it's Windows or Web, is dependent on a broad set of Microsoft technologies. And we're vulnerable to them changing any one of those pieces. Well maybe, Microsoft itself, by accepting some of these dependencies, will start to understand our pain, and will come up with interesting ways to address it. Basically, if they fix their own problem, they will inadvertently fix many of our's also.

DDJ: That's an interesting perspective. On one hand, yes, the SQL Server team probably filed a lot of bugs. On the other hand, the SQL Server team was probably saying, "You have to ship, because we have to ship!" And I guess that's no different than customers who start building products based on a Beta version, because they've been "promised" a certain release date for Visual Studio. They also need the Framework to ship, because they can't ship until it does.
Kathleen: As somewhat of an aside, the most expensive decision I ever saw regarding moving forward was to not move forward. Not moving forward can be as expensive, or even more expensive, than moving to the newest version. It turns into this big gamble for companies that have real people driving trucks or making doughnuts, to decide when to move forward to a new technology, and a lot of it comes down to how much they can trust the release dates announced by Microsoft or any other company.
Billy H.:I guess I'm just pessimistic that this won't get any better. The problem is that we have so many platforms now. We have the Windows platform, and the .NET platform, and the SQL Server platform. Soon we'll have changes in the form of WinFS, which changes the platform. You pretty much have to have all that stuff working right, before you put anything on top of it. As bad as it is to have products wait on other products, I think it's even worse to do things incrementally. Part of the problem today is that Windows XP doesn't have the .NET framework on it. The platforms got out of sync. As much as I hate the delays, I think the platforms have to be synced up, to be the fundamental foundation on which we build.
Rocky: I really don't think this current rate of change is sustainable in the long run. I don't think that the corporate world is going to put up with it. For any investment they make in Windows or Web right now, they have to be concerned about how much of that will change with Avalon. If Microsoft turns around after Avalon, and comes out with more radical changes, I think they really do run the risk of losing people.

DDJ: It sounds like the core question is quantity vs. quality. I think the question to Microsoft is, "You know that you're going to have tool support for all these new technologies, like WinFX, Atlas, and so on. These new technologies aren't small things. How can you add in tool support for all those technologies, in a relatively short time frame, and still insure that the tool is stable and high quality?" It seems like a tall order.
Kathleen: But we all said that we want the new features. We all said that we wouldn't go back.
Bill V.: I think the third parties could expand their role. If they knew that the platform would be stable for a long time, and they weren't going to have to rewrite their stuff every couple of years, they could go a lot farther.

DDJ: But we've all said, "Please, Microsoft, put this feature in the box so that I don't have to go to a third party for something that's this fundamental. I don't get the same support from a third party. Their stuff is often practically undocumented. It's not as stable. Loading add-ins can hurt the stability of Visual Studio." Don't get me wrong, I end up using 3rd party products in every application that I work on, but it's one more layer of stuff that can cause problems.


It almost sounds like we don't know what we want. On one hand we're saying, "Stop! You can't change this fast." And then on the other hand, we're saying, "The changes you made for 2005 are so good that I'll never go back." The changes that they make for 2007 will probably be just as great. As soon as we see them, we'll say that we can't live without them, and we'll say, "What's taking so long to ship the dang thing?" Once we get it get it, we'll say we won't go back. If it's not stable, we'll cuss about it not being stable, but we'll use it and recommend it anyways. Are we just at a point where we have to resign ourselves to a certain level of frustration? The technology is going to change fast, and while in abstract, we don't like the rate of change, when we see specific features, we want them very badly. We'll push to have it ship soon because we want to use it for new products, and then when it does ship, we'll point our fingers at it and say, "It should have been more stable."
Rocky: The problem, I think, is that it's all being driven by geeks, and we're geeks too. Most business applications are forms over data. All of these new technologies exist to feed the technology frenzy. They don't actually make it any easier for the user to type in the data that gets entered into the database. None of this stuff is really benefiting the user. It makes it prettier, whatever, but it's all technology driven for technology's sake. That's all very cool, and as geeks, we all love that. Microsoft loves it because they're all geeks too. But I just wonder how sustainable this rate of change is in the long run.

DDJ: Everyone, thanks for taking the time to chat.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.