Friday, November 04, 2005

Are you in the Seattle area as of Wednesday the ninth? Well, there's a little shindig in Bellevue that all the Microsoft shareholder cool-cats are invited to. More info at: http://www.microsoft.com/msft/SEC/FY05/proxy2005.mspx . Note that there will be an audio web cast that you can find off of http://www.microsoft.com/msft/ - put that reminder in your calendar. I hope to get a post up for people to share their reactions.

Maybe next year I can be more organized to print up my own little pamphlet of MSFT Common Sense to hand out for the arriving attendees (you know, one with the share price graphed on the front).

One topic that would be in there for this year: does it make sense to ship a product that your own customers are telling you, "No! Please don't ship it yet! Please make it more stable and performant! Please, for the sake of all that's holy, take your time!" Sorry, customers, here it comes!

How has reaction been to Visual Studio 2005 so far this week? Here's a sample of six:

I think that it's imperative that the tools we're using to help us develop will actually.. well, help us develop. If I find myself working in spite of a tool, I'll look elsewhere to something that will replace it. Until now, VS was the crowned king of the .Net IDEs, but with those problems, it's possible for a competitor to show up and turn the tables on Microsoft.

This is integrated innovation loaded into the cylinder and blowing a big hole in Microsoft's foot. Because so much was tied to VS 2005 and CLR 2.0 it had to be shipped now, ready or not. Has all of this been shoved out of the door in order for SteveB to be rushing straight from the launch celebration and into the shareholder's meeting?

I might wander in early on Monday to meander through the crowds celebrating the big Visual Studio launch. But my heart is heavy that we shoveled what we could together and Won't Fix-ed this release out the door. Microsoft has just opened a very big door to competition in the IDE space. Or at least towards people jealously holding onto VS 2003 and saying, "CLR 2.0? Screw that! The last time I tried to use generics my machine locked up!" Big freakin' mistake. Microsoft should be ashamed.

And shareholders should be pissed off. Do the shareholders know any better? Are they going to wander into the Meydenbauer center on Wednesday clued into the fact that our developers developers developers have just been screwed screwed screwed and the first thing out of our innovation pipeline has so far landed with a wet thud? Zero common sense.

If you can't trust your compiler, man, your whole world starts falling apart. All of you Microsofties posting "whoo-hoo, we shipped!" to your blog I hope are going in next week and, after the cheering, put deep concerted effort into creating a near-term service pack for VS. I know we wander around joking that Orcas will really big a big service pack for VS 2005, but as of this week, no one is laughing. Our customers - our developers - deserve a lot better quality and we need to react quickly to avoid a deepening distrust.

I'll be keeping an eye out for further VS 2005 problems. If you find any other interesting reports, please add them to the comments here.

(A big iterative tip of the hat to the mixmaster sending me Roy Osherove's link and the core thesis for this post.)

77 comments:

We all get your point. But I seriously think that your blog has outlived its shelf life.

If you have an issue with VS 2005, take it up with Somasegar. If you feel Vista is buggy take it up BrianV. They'll be glad to take time out and listen to your feedback.

But slamming soon-to-be-released products in this manner is simple not tolerable. If you have concerns then voice them by all means, but behind closed doors. If you start washing dirty linen in public, then even your most ardent supporters will turn their backs on you.

I'm fairly exclusively Linux these days. Back in the days, however, I was a beta tester for Windows 98 and 2000. I think I can even sign my name on the fact that you can do a two clicks cancel of the annoying "Internet Connection Wizard" to get it to go away for good. I had to nag the dev team real hard (i.e. - keep reopening the bug) on that one.

One of the first RCs for Windows 98 added the new requirement for a CD key. Up until that point, the beta simply installed. I filed a bug saying "The use of a proportional font for the CD key is ugly. It results in the characters not filling up the boxes right".

The reply? "We are too late in the development cycle to change that". Well, duh! You only added it just now.

It gave you the feeling that your feedback is not really important. You are an annoyance for trying to make their product better.

I still use VS 6 for all the (blissfully rare) cases I need to do Windows development. All of my clients also use VS 6 for their own (typically Windows only) development, avoiding an upgrade like the plauge. One of my friends does work on VS.Net, and curses every moment.

The concensus where I'm standing is that VS 5 was the pinnacle of the line, with every successive version being a steady downhill (UI wise) since. I'd be using VS 5, except the C++ compiler there is noticably inferior to the VS 6 one.

Shachar Shemeshminires@shemesh.biz

p.s.Get a hushmail or some other secure anonymous email. Right now, there is no way to send you private comments, or, say, send you feedback at all when you disable the comments....

I love the comments in the hang bug, "we'll look at fixing it in the next release." I hate the triage process where we fix or punt bugs. I hate the excuses for not accepting a fix.

I wonder if the decision process will become more rational now that there are blogs where people flame bugs. Users have zero tolerance for hangs and crashes. We used to just worry about the reviewer from pc week running into a bug. Now we have to worry about thousands of bloggers running into a bug.

My pet peeve ... having a bug marked as won't fix because there is a work around. How's a poor user supposed to figure the work around.

But slamming soon-to-be-released products in this manner is simple not tolerable. If you have concerns then voice them by all means, but behind closed doors. If you start washing dirty linen in public, then even your most ardent supporters will turn their backs on you.

But slamming soon-to-be-released products in this manner is simple not tolerable.

Um, hello, he's pointing out where customers are slamming a RELEASED product- and where MS employees are admitting that they shipped something with crashing bugs. Double-You Tee Eff? Since when is a ship date more important than a quality bar- especially when customers are TELLING you they need a high quality bar?

(I think this is where somebody is supposed to tell us all how it's a good thing Microsoft's getting rid of all that useless tester overhead these days.)

You might recall that way back in the 1970's, Microsoft started out as a company that supplied software to developers (MS-BASIC, etc). Arguably, this is the core of Microsoft's DNA, providing software and value to developers- and these are high-value "influentials" who basically got ignored- and then got a buggy product to boot. Ooops.

Also, don't forget, a lot of INTERNAL groups are going to need to use VS 2005 for cool features in Vista. So customer pain = Microsoft pain acros product lines as well.

You do have to eventually ship so that we can make money and realize value for our customers, and that means hard calls and deciding that there's more risk taking the fix - a fix that might cause more problems - than not taking the fix.

Chris Pratley talks about this real well in his "More on Quality" post...http://blogs.msdn.com/chris_pratley/archive/2004/02.aspx

The customers were saying "We'd just as soon you spent more time bugfixing Whidbey rather than hitting the ship date" back in August, if you'd read the links Mini has helpfully provided.

MS decided to ignore that in pursuit of an arbitrary ship date. But look at the customer value they shipped! Customers really value buggy IDEs!

And yes, duh, you can't fix everything. Nobody's arguing that. But you CAN decide on a quality bar that is what you are satisfied with shipping, and the initial feedback's pretty clear that whatever one got picked for Whidbey, they screwed it up.

This is a prime example of what's wrong with pulling six blog comments out of the blogosphere and holding them up as proof of a poor decision. I'm willing to bet, though am too tired to actually do so, that for every negative comment you'd be able to find 15 or 20 positive comments. Yes, there are people who are unahppy, and we need to fix that, but we also had a lot of customers beating the door down asking us to ship the stuff.

I'm also anxiously awaiting your comments on why the CLR is bad for MS, that you mentioned some time ago.

Mini, you might want to try using the products your own company produces before you declare it an utter failure and the buggiest thing ever.

I've been using Whidbey since PD3 was made available. If VS 2005 shipped with the PD6 build, I would agree with your sentiment -- PD6 was an abomination, and I was pissed that something with such piss poor quality was released outside of devdiv. The RTM build is not PD6, not by a long shot.

The fact that we shipped a product with known bugs is not unusual. No product on the face of the earth was shipped bug free. You of all people should understand that triage process, and what it takes to ship a known quantity and why it is important.

Sometimes triage has to make a hard decision. Sometimes they make the wrong decision. To someone impacted by a bug, it is always the wrong decision. But it is also the only way a product will ever make it out the door.

The only problem I've had with the RTM build was related to bugs in the PD/Beta uninstalls -- had no end of problems until I cleaned out the registry by hand. A clean install has been rock solid for me, and so far I haven't found anything to complain about.

It seems as if this blog has recently changed its tone from something that offered constructive criticism and useful insights to the kind of drivel you'd expect to see on slashdot.

This is a prime example of what's wrong with pulling six blog comments out of the blogosphere and holding them up as proof of a poor decision. I'm willing to bet, though am too tired to actually do so, that for every negative comment you'd be able to find 15 or 20 positive comments. Yes, there are people who are unahppy, and we need to fix that, but we also had a lot of customers beating the door down asking us to ship the stuff.

This time VS2005 was allowed -- intentionally -- to ship with severe bugs, which cause irreversible loss of the user's work and require hard reboot of their computer.

Here's Frans Bouma's answer to MS Suma:

Frans BoumaPosted @ 11/4/2005 8:39 AMSuma: well, as you can expect: I can't wait till Orca's for this to be fixed. So I'll escalate this bug to get a hotfix immediately. It's simply impossible to wait a long time for a fix for an editor hang. The problem with an editor hang is that you've the potential of losing work and that you probably have some code windows open you're working on, which you have to re-setup after you've restarted. Unacceptable.

Next monday, on the launch party of VS.NET 2005 here in The Netherlands, Soma is here and I'll ask him what the policy is for service packs for vs.net 2005, because I truly hope MS isn't simply ignoring bugs till orca's comes along. "

Seems like someone from Microsoft's Board of Directors (guess who) so badly wanted to have the slogans "Ready to Launch" and "Get Ready to Rock" for the Microsoft's Annual Shareholder's meeting, that this person completely neglected the quality and the users, doing to Microsoft even more harm...

Seems like people wanting to be reelected at any price and completely, deliberately ignoring the interests of the company in preference of their own personal interests.

Certainly, this will cast a long shadow on SQL Server 2005 and BizTalk Server 2006 -- if VS2005 was so bad, how can we be sure the other two are any different?

A long shadow over many of the products to be shipped in the future.

This is the first time I'm really ashamed to be working for Microsoft.

I'm joining in this as someone who used to to a lot of win32 dev, but is now so firmly in the Java camp that I work on Ant, the build tool that is the moral grandparent of MSBuild.

Question: why doesnt java get into this mess. Because everything is loosely coupled. The Ant team release stuff on on their schedule, after its own beta cycle. The IDE people ship with the last major release, but always provide a switch to say 'run against a custom version', so users can upgrade the IDE components just by flipping a switch in the IDE. Similarly, you get a choice of IDEs, with free ones classifiable as mediocre (eclipse) to awful (netbeans), and intellij idea actually worth paying for. These IDEs ship on their schedules.

There is no single unified push towards a grand release of everything; no java1.5 shipping on the same day as ant1.6.0 and eclipse3. everyone depends on each other, but releases on their own their own schedule.

This means that the latency of getting everything out is bad, but when things are released they are pretty stable. Also, all 3 main IDEs have a very regular update schedule, essentially quarterly. So there is no grand ocean-boilder of a product release, just a gentle heating of the local area. It may not make for such great press, but it probably brings the stability developers need (Java1.5 gaping bugs notwithstanding; that's been out a year and takeup is still pretty low)

Well, all I can say is that I have been using the Express versions for months and I never had a problem. Other devs in my old company were usig Team Studio and never complained.

I say that it's easy to say "it's buggy" or "it sucks," but it is a lot harder to actually make a Dev IDE. Hopefully it's not as bad as some make it sound. The advantages of 2.0 FX and languages should not be overridden by bugs that should have been fixed.

For several products, employees are required to use the product as our customers would use it before it ships.

In a lot of groups, the VS IDE is not used by developers.

The build system does not use VS generated make files.

I remember one meeting where Jim Allchin recited the list of steps required to perform a simple operation in one of Microsoft's products. Everyone started laughing as the list went on and on.

A lot of kinks get worked out of products by other groups using them before they ship. The products Microsoft ships push the limits of other Microsoft products using them. When they are modified to meet those needs, the product gets a lot better.

All MS's code is *tightly coupled*. Internet exploder is coupled to the OS. AD is coupled to the O/S. Exchange is coupled to AD. The AppDev IDE is tightly coupled to the OS, etc, etc.

This tight coupling across product lines *may* bring more revenue via customer lock-in (if I want office, I have to run on windows, etc), but it does cause hellish delopment nightmares.

Its as if the senior architects are still living in the '90s (for some reason, I had this mental picture of mullets and 'porn-star moustaches'), and are convinced that tight coupling is the ONLY way its going to work.

Why not "loose" coupling ? Why not *let* microsoft products run on multiple operating systems and/or databases ? Why not accept that some folks out there actually DONT run windows server in the datacenter, and support "big" tin such as Solaris, AIX, OS/400, zOs - or even - gasp - linux ?

Ah. Perhaps the problem is that the chief architect himself is a major shareholder, and unlikely to change his mind ?

And this "it has to run on windows" mentality continues, regardless of the current inability to ship product (thinking of: Vista Reset, Exchange "kodiak", etc, etc)

My team found a number of alarming and some merely annoying .net bugs. When they bothered to respond it was to tell us they wern't going to fix it and in manmy case had know about the issues for some time. Another great product and team crushed under the churning tracks of the date driven release.

There are two things important when a bug is found in VS.NET / you run into a bug in VS.NET:

1) the reason behind the bug, so you can work around it2) the knowledge that there will be a fix in an upcoming service pack.

The NUMBER ONE thing I hear in the community is that Microsoft should release service packs for vs.net. There is NO excuse for not doing that. I ran into this IDE hang bug, and after Cyrus explained what was the cause of it, I now know how to avoid it, but that doesn't mean I don't want it fixed/need it fixed: others don't know this info and run into this issue and will lose work.

It's always been a mistery to me why Microsoft never released a service pack for the previous VS.NET versions, they always did release service packs for other visual studio versions.

I don't expect an RTM version to be bugfree, I know the hard way that no matter how hard you try, there always will be bugs in your software. That's ok, as long as there are fixes released, patches available for everyone.

I believe vs.net 2003 had 1 public patch in 2.5 years, while there are a lot of bugs fixed in those 2.5 years, but these fixes were never released. That's not a strategy. That's lack of respect for your customers.

I've said this before: if I treated my customers the way MS treats them, when it comes to patches, I wouldn't have a customer left.

I really think that most people, myself included, would find it essential to know when and IF there will be a service pack for vs.net 2005. And no hollow promises like there have been about service packs for vs.net 2003, because that service pack never showed up. It just takes a strategy for fixes distribution, and it's a strategy which is necessary if you want to claim that you provide GOOD quality and GOOD customer support. Support isn't just putting examples on the website. Support is more: providing fixes for free on a regular basis. If office can do it, why can't VS.NET do it...

Somebody once mentioned that Mini is a lowly serf slaving it out in one of the meaningless BUITs on campus. The accuracy of that analysis is proven with every latest write-up of his. While there is value in his original angst that led to this blog, more and more he is proving that he has absolutely no clue about software engineering and is not plugged into the mechanics of decision making in any of the product groups.

Mini had no idea of Vista shipping date (see Dare Obasanjo's blog for details). He is slamming products like VS 2005 because they are shipping with bugs. I doubt Mini has attended any product's war room before (you have to be somebody to attend and participate) and I feel bad having to explain bug bars, exit criteria and all that stuff to Mini.

Same goes for all those that have posted their annoyance with processes or folks that wonder what PMs do. My advice? Get a good mentor real fast and learn the ins and outs of software development at MS. Don't be cooped up in your little room waiting for your lead to hand you bits and pieces of work. There is a lot more to MS that you will not discover in your little island.

Remember your mentors must not be first-line developers like you. Find a solid PM/Dev Mgr/Test Mgr/PUM you admire and say, "I'll like you to be my mentor".

Believe me, you'll learn a lot and will not have to come to a blog like this to cry about things.

It's too bad that VS isn't a shared source offering. Why does it need to be a closed source product? For one thing, it's a gigantic mess. Maybe Orcas will be developed from the ground up, enabling external developer involvement in the bug fixing, as opposed to limiting customer involvemnt to simply logging bugs in a central database.

Times have changed. Open up VS and let the world help fix our bugs and innovate the platform, not just innovate on the platform.

Well, it takes quite some time for a new hire to learn VS and how to properly fix bugs (like months). Even experienced developers coming from other groups need time to ramp up, learn architecture and processes.

I simply don't believe that random external developer would be able to fix bugs correctly. VS is huge, and I am sorry, experience with 10,000 lines product simply does not apply to 3,000,000 lines product.

AFAIK, 99% bugs in Mozilla are fixed by full-time developers, not by external folks.

Just to get things out of the way - yes, I am am MS employee, and yes, I am thoroughly depressed by this entry - perhaps because I know that at least some parts of it to be very true. What depresses me even more, is the misplaced sense of indignant patriotism, which some of the fellow microsofties appear to hold on to.

If you have an issue with VS 2005, take it up with Somasegar. If you feel Vista is buggy take it up BrianV. They'll be glad to take time out and listen to your feedback... If you have concerns then voice them by all means, but behind closed doors.

May I ask why??? This is exactly the kind of thinking which made everyone in the Eastern European Bloc believe that only positive image should be projected, and any criticism amounts to treason.

"But slamming soon-to-be-released products in this manner is simple not tolerable."

Bah. If there are bugs in the product that will force certain customers to consider alternative products, it's time for a little glasnost and perestroika.

As I see it, the core problem here is Microsoft's corporate obsession with making marketing promises years in advance of the ship date.

Not least among the resulting sins are the initial promises regarding a ship date. However, worst of all is the fact that I have never seen a single MS product (including those I've been involved in) meet or beat the initial marketing-driven hype.

Want proof? Go back and look at the promised feature set for .NET and Hailstorm. Look at the promised feature set for Longhorn, before it was downgraded to Vista. I could go on, but it's too painful.

The only real suspense prior to a Microsoft release is whether the Marcomm folks will have enough information about the product that will *actually* ship to set customer expectations appropriately.

Until we get marketing out of the driver's seat, we'll continue to see this type thing. Sadly, even with the Blogging Jihad, we are still run by marketing and the old school is as strong as ever. Time for Bill, Steve and the rest of the old guard to retire on their own beaches on their own islands.

Why does everyone act as though this is a magically-new issue that started with the Visual Studio 2005 release?

Remember the pre-blog days, with the hundreds/thousands of people BEGGING Microsoft to fix the insane kearning (text spacing) issues with GDI+/System.Drawing.DrawString? Have you ever tried using that method? It makes your app look like crap, quite honestly. This has been around since .NET 1.0, and I would say affects every WinForms app ever created. Do they care? Has it been fixed? No.. BY DESIGN. WONT FIX. etc.

I've been running 2005 for quite awhile now and for the most part it hasn't been any buggier than 2002. Microsoft prooved to us with the 2003 edition that they have no interest in releasing service packs, only new products.

Why? It's probably not entirely a random marketing decision. The IDE is tied closely to the framework versions - makes releasing a service pack much more difficult.

Personally, I'd rather use an IDE with a few small bugs (that people are blowing out of proportion) rather than have another minor release. There are lots of 'must haves' in this release, and it would have been a shame had they been cut. I got to spent last week ripping out custom Interop code and replacing them with the new framework classes/methods. What a great feeling what was :-)

The reality is that, regardless of how much testing/QA you put into a product the size of Visual Studio, a brand spanking new release is always going to contain some sort of problems which make it into the official release. The question of whether to adopt it boils down to your attitude to risk and how hungry you are for the new features. It you're sensitive to risk, you'll play the waiting game, and let other people sort out the teething issues in the product. The reality is, that if you're working to a fixed cost of deadline the last thing you can afford is your compiler refusing to work correctly; however trivial the problem may be. If, on the other hand, you have the bandwidth to cope with trying different workarounds, trying out sexy new technology is the best way to go; there's definitely more excitement/reward in doing that.

Where you really don't want to be is dependant on some new feature of the product which doesn't work as well as you expected; and stuck in the middle of a project with a looming deadline and no alternatives!

Mini,It appears your fear of being “slash-dotted” was well founded. Prior to that event, I learned a great deal about the inner workings of Microsoft’s ranking system and management problems and it even appeared that you were making a real difference and winning the hearts and minds of many people. However, with this post the tide has truly turned. I don’t know if it is the feeling of having the hoards of Anti-Microsoft posters on board now (the enemy of my enemy…) but it’s obvious that you have crossed a point in your previous mantra “I just want to make the company better”, to “burn it down!”

I think it is good that Microsoft shipped Visual Studio 2005, even in this state. At least RTM means that it has support, while CTP does not. I have been working intesively with the IDE for months and I know it is still buggy, but most problems have workarounds, and Microsoft can afford this situation better than the no-ship situation. I don't need a service pack in six months. I prefer the 20% of the bugs that make 80% of the annoyance fixed much earlier. That 20% for me means the "Visual Basic background compiler crash", and the "IDE vanishes while opening solution" bugs.By the way, Microsoft right now has no means of estimating the actual number of occurrences of the crashes, because most developers click on "don't send" button when the watson tool surfaces. You can read details here: http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=322ae430-60f9-4ce2-bd4f-db88de777a79

I hope the adults at MS (and they aren't necessarily in management) get this straightened out.

I feel sorry for the MS employees who feel that telling the truth about a product is "bad" & must be stopped. Would you rather this come out ahead of time, or would you like it to come out after you ship, with the added tag of "MS knew about this months ago & shipped anyway."

Sure, there are 'bugs' in shipping software. Sometimes it's by design - no, MS Word isn't designed to handle 1-billion row calculations on embedded tables. Sometimes it's by the edge-case scenario - very few left-handed people with disabilities will need to use the color-picker with a Wacom tablet.

But a bug that causes a data loss seems to me (a mere outsider) to be pretty serious. And it doesn't appear to be an edge case.

It seems to be pretty easy to attempt to discredit this blog because it pulls the drapes down.

But perhaps in the 21st century secrecy in software development will go the way of the mainframe computer. One would hope that MS would start paying attention to this shift in business strategy.

We have a problem that we noticed as soon as we moved from Beta 2 to RTM. We have about 26 projects in our solution. Some of these projects reference their peers. If you open a designer, run the application, and then stop the application, you cannot open any more designers unless you restart the entire environment. This defect is probably going to force us to roll back to VS.NET 2003. The error reported by the designer is: "Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. We've done some analysis using FileMon from SysInternals and it appears as though the 2005 IDE is failing to properly update it's internal DLL references (which are actually .TMP files) after it builds new versions of the DLLs in the bin folder. So far we can easily and consistently replicate this problem on our Pentium-M development laptops. I sincerely hope something is done to resolve this immediately because we cannot use the product as is.

Microsoft have a very long track record (what, over fifteen years now) of shipping buggy software. Thus users will accept the product and overlook the bugs, simply because their expectations are so low --- everyone knows Microsoft products ship buggy. Customers may "deserve" better, but trust me, nobody is "expecting" better - not when the box says "Microsoft" on it.

Microsoft isn't agile and never has been. Microsoft doesn't make quality products with very few bugs, and never has. These things will never change; Microsoft succeeds in spite of them. It's just not in the 'corporate culture'. In 2010 we'll be having the same conversation about VS 2010.

I tried to post a link to this thread as a comment on one of Somasegar's WebLog entries, and guess what? - Within an hour my comment entry was magically removed. Guess he doesn't want any rain on his VS2005 parade.

Does VS2005 include bugs? Any one would be kidding if he/she said NO. No product is bug free. Does VS2005 add value to the developer experience? The absolute answer is YES. Great value. I have been using it for my VC++ development and it is is just amazing. All the new features and platforms supported. Great work and hard effort!

Having done software myself for 20 years I have some compassion for the ship or die argument but some of the MS types comments border on the hysterically delusional; no real gate crashing bugs shipped?

LOL.

If Mini is wrong it will be proven in short order, personally insulting him/her is really more a sign of immature arrogance than any expert knowledge on the part of the attackers.

Personally I smell the whiff of "Cats out of the bag fear" on some MS types more than anything else.

The way that reported bugs were handled can only be described as arrogant, childish and short sighted, and thats personal experience not hear say.

My team would read the repsonses from MS for a "Dark humor relief moment" during development, still are actually.

From a "Today" stand point we have confirmed there are some serious issues not only with VS2005's IDE but the CLR itself and if not fixed will cause some real deployment pains.

You think it's bad now, wait until people starting shipping product with NET 2.0 into the wild, what a ride thats going to be.

Can we work around them, well I guess we have to since MS refuses to acknowldge their importance, sad really.

Borland kicked MS's ass with a killer IDE, then MS put the hurt back on them, makes you start thinking about why monopolies are bad.

"Hello world" works great of course so for all of you writing tini-sample apps it's a great product and good luck with it.

Real world developement? Well thats a whole other ball of wax.

In my opinion anyone who says they didnt encounter anything serious in the VS2005 cycle, including and up to the released product just hasnt excercised it that much or is writing such trivial applciations that they arent seeing anything of note because they are not writing anything of note.

I thing Microsoft sould release his next version code ide because will be good for the developpers. Some bugs seems very critical, so.. before the release a service pack sould be release to fix that bugs. And more efforts sould be driven on fixing that bug.

For what it's worth I think VS 2005 has some bold innovations and is conceptually a great leap forward in MS's development products.

However, in what is actually a really small development project I have encountered a whole host of bugs and crashes that I NEVER encountered when using Beta 2 (which is the only reason we ported the development from VS2003).

These problems range from the constantly and continually annoying IDE crash, to forms designer malfunctions and a disastrous interop problem with ActiveX in the new WebBrowser control, to the almighty system wide instability I've encountered since installing the Release Version of .NET Framework 2.0.

I am now faced with the decision on whether to persevere with the problems or spend an awfully long time trying to port the code BACK to VS 2003.

And before you mention it again, it's not just a case of installing on a clean machine that has never had a previous version of 2005 installed. Initially I simply uninstalled the Beta but upon having problems from day one I rolled my machine back to a 'ghosted' version that had never had a beta version installed. In fact some of the crashes / machine lock-ups have been so severe that I've had to do this three times in the last week alone. Even when using / testing the Beta versions my machine was stable. Now it's like Swiss cheese... (I have to re-boot at least five times a days after multiple processes lock up.) No offense to Swiss cheese-makers. And the ONLY thing to change has been the install of VS 2005.

I have spent the last seven years building up a career solely using MS development products.

For the first time I am seriously considering making a switch.

For the first time I have lost confidence in Microsoft.

If I released an application that had, for even one customer, as many problems as I have encountered with VS 2005 RTM, I would consider the product an abject failure. I have never encountered a product that is so difficult to give my continued support to. Until MS comes out with some hotfixes or a service pack for VS 2005, I WILL NOT be using, considering or recommending Visual Studio 2005 for new projects.

Ultimately all I want is for VS to work not ALL of the time but MOST of the time. At the present moment it has become a nightmare to work with. And to think I payed so much for the privilege...

It's kinda like bringing home a new Porsche that you have to leave in the garage.

Stumbled across the blog while browsing for VS.NET 2005 entries. I've been working with the IDE for a few days now and it just sucks. It's painfully slow (on my idle high-end machine), designers are not responsive it often crashes and sometimes even hangs that bad that only a reboot can help.

While VS.NET 2003 definitely has it's issues, the quality of the new IDE (which is supposed to be a better, more matrue product, isn't it?) is just hilarious :-(

On VS.NET 2005 IDE (VB6 IDE on steroids), I have heard many complaints about random hangs due to Intellisense. Thing is, I also experience hangs with Intellisense but I am using Visual Studio 6 (with the latest SP), and I believe this will never be fixed.

I would concur that for now it's perhaps best to go download the free command-line editions of compilers, and use another IDE.

I read the comments here with the interest of a person facing a 6 month deadline for a moderately complex application that has an absolutely hard deadline of May 1, 2006.

From what I read, numerous issues exist in VS2005. If you review what is written here and elsewhere, you wonder if the product works at all.

Which brings me to the following questions for response:

Does the installation of the VS2005 product cause corruption of the machine if the install abends?

Once installed, does the environment produce executable code that is distributable as an application for moderately complex applications?

Do the compiled applications from VS2005 crash upon execution, are they moderately stable with buggy interfaces that did not produce expected results, or do they run fine in most environments?

Are most of the problems in the IDE with Intellisense?

If the IDE is the main issue, are the source files becoming corrupt? Does the IDE corrupt the rest of the machine you are trying to run it on?

Are there more problems in C# than in VB in the VS2005 environment?

Can any of the problems be tied to internationalization problems (character sets besides English, etc.)?

Just curious as to what, EXACTLY, are the main issues with the product. If we concentrate on the really critical items, maybe someone at Microsoft will listen and give us a SP .5 patch to fix the big items.

And, no, I do not work for Microsoft. I am just trying to make an informed decision.

As a shareholder, I have a couple of questions for anyone who can enlighten me:

First, do (some, many, most) MS development teams write unit tests for their code? I'm talking about tests written by programmers for programmers to ensure that public interfaces work as expected, whether the tests are written before the code or after?

Second, what's the most common pathology for bugs (exluding performance, scalability, and compatability buts) in a typical MS product? Modules that don't don't satisfy their post-conditions? Integration bugs where one module is violating another's pre-conditions? Something else?

Just wanted to do a trackback, but unless I'm missing something Blogger only allows this for other sites on the same platform - very poor! Anyway, taking this from a corporate blogging frame, Scoble points to Mini in talking about genuine voices:http://scobleizer.wordpress.com/2005/12/16/corporate-and-political-blogging-get-rid-of-the-fear-be-yourself/and I think the VS 2005 story is a very nice example, particularly as it was then taken up by Channel 9:http://channel9.msdn.com/ShowPost.aspx?PostID=133456#133456See my full post on all this at:http://www.rossdawsonblog.com/weblog/archives/2005/12/steps_to_corpor.html

I have to agree 110% with the comments made by Paul Sorauer, the problems he describes and predicament he's in exactly mirror my own.

Occasional problems that can be avoided are expected. Serious problems that get patched in a week won't actually hurt the product. Unfortunately there are serious problems and the message I'm getting from Microsoft is "This is not how we see ourselves, so we don't want to know".

The problems I'm experiencing seem to stem from two sources; Assembly versioning doesn't work properly, and there are untrapped memory leaks (probably in the OS kernel modules). While this is costing me time and money to work with, and may well ultimately cost me the two year project I'm working on, no fix is forthcoming, Microsoft won't 'own' the problem, and I'm actively looking for alternatives for my next project.

So Come On MS guys, stop saying "It's not our problem" and start saying "This is how to fix it now", 'cos in six months time I for one won't care.

I don't care about all the innovative, cool features if the damn thing cannot handle the basic stuff. This is really becoming an exercise in frustration. I cannot believe MS screwed up so bad with such a backbone product.

My gripes:

1) Disgustingly slooooooooooooooooooow.

2) First try: Compiler gives validation errors and refuses to build the project. Second try: Compiler gives same errors above. Third try: compiler is happy and builds project just fine. WTF????

3) As many people said, VS 2005 crashes every now and then. Not just the nice, baby-style crashes. I'm talking total machine freeze. Way to go guys.

4) Migrated projects seem to work at first (build fine, sometimes). Yet, it seems the functionality gets royally messed up due to small 'features' that MS ingeniously added, such as EventValidation.

This is really frustrating, I guess MS found that too many people were migrating to C#, and wanted to slow the crowds at the gate by providing this God-awful piece of crap, codenamed VS 2005. What is even more shameful, is that MS is totally ignoring the numerous problems in its $1000+ product. Unbelievable.

I can deal with minor bugs. They’re expected in any application and as a software developer it’s hard for me to point fingers. That being said, the issues I (and my coworkers) are facing with VS 2005 are unacceptable. I'm talking about ~10 crashes a day and VS eating up over a gig of RAM. Sadly I've now resorted to developing in Notepad and only open VS when absolutely necessary. I agree with Mini and others; this isn’t something that should be swept under the rug.

To all those who say the bugs are tolerable, understandable and "not that bad". I'm a MS developer on a team of 10 plus outside devs. We have a project. We have a deadline. We require this tool to get the job done. When the tool hinders us more than helps. When the tool crashes every 15 minutes (literall). When basic features that used to work no longer do, That's a BAD product. Spin it every which way. It's awful. MS doesn't have a LEG to stand on here. We're using enterprise edition. We're doing enterprise development and it CAN'T HANDLE IT. Awful stuff.

Imagine for a moment that the ship date was allowed to slip by a few months, into early 2006.

The company would then have to choose between

- launching "VS 2005" in CY 2006, to inevitable jeers

- renaming the product to "VS2006" and updating all of the docs and marketing content

That merely a side effect of the ridiculous calendar year naming convention. If they went back to sensible VERSION numbers, they'd just release Version 8.0 when it was ready, and no one would see the discrepency in the year of release and the year in the name. Then If version 8 was ready in 2005, Great. If in 2006, great. As long as it's READY.

I'm just doing some evaluation/prototyping of MS SQL 2005 and it seems that the curse of Dev Studio extends to SQL 2005 BI Dev Studio. The report builder part of IDE crashes about every 5-10 minutes... And I'm just using the very basic features... Not very encouraging

Wow... 3 months already since the release. One would think that they would have posted a patch or something

I have been using VS 2005 for a while now...I would say it is rich in features, but poor in stability, efficiency, and overall bugginess (but after all, would you expect any less from Microsoft?). I have had it crash on me many times. The crashes are very annoying, but admittedly the new features are nice.

I am actually amazed that adults who (supposedly) develop software and USE this garbage can feel it is acceptable. SHAME ON YOU!!!! Remind me to never feel safe using software that you worked on. This was the most pathetic step backwards I have ever seen.

I was in charge of designing and executing the shift from 6.0 to 2005 for our product and it was a royal mess. I think that just about the only thing that keeps us from going back to 6.0 is the time required to reverse the process. Does anyone know what happened to the Class Wizard? The new replacement is awful. I personally don't care to wait 2-3 minutes every time I add a variable or message handler for the dialog I designed. The new design is useless since I might as well just do it by hand. If my screen needs a modest 10 message handlers and 10 variables I could add them in 2-3 minutes total in 6.0 but this great new design lets me waste 30-40 minutes of my employers time and say I am working.

While we are talking about wasted time; the new compiler is about half the speed or slower not including the even larger increase in to time required to build the browse info file. Does anyone but me use Edit and Continue? Do you like the new bug that crashes the IDE if you hit compile and say "Yes" you want to stop debugging? How about the fact that you could recompile twice in the time that it takes to just relink the Edit and Continue changes?

I think a personal favorite of mine is the Intellisense Parser. I just love it when my whole computer stops operating for a couple minutes while the parser parses the entire project all over again. This makes editing large scope header files so much fun when every new line causes a several minute lag. And if you are from Microsoft don't you dare tell me that these bugs don't exist or that I should report them to your silly database. That list is a sorry excuse for a black hole to dump my bug reports in. I can file a report and maybe, if I am lucky, you will consider fixing it when you get around to releasing a patch 9 months to a year after you released the product. Critical fixes that prevent things like IDE hangs should be released no less than monthly, not every few quarters.

Now to your credit on the IDE hang thing, there is a new feature that recovers files if the IDE terminates abnormally. To the credit of all us developers that are complaining, the feature doesn't work. I only recover lost work about 10% of the time and with about the same frequency I loose work that I already saved manually (don't ask how, I don't know, I just re-write code.)

Memory leaks are great too, 6.0 did a better job of tracking allocated memory and letting you see where the leaked memory was allocated while 2005 seems to fail at this the better portion of the time.

Doesn't everybody love the help integration with MSDN? Oh wait, WHAT INTEGRATION? I believe that the last I heard this was scheduled for the already pushed back first service pack?

The point has been made that you chose the features and decide whether the new "Must Have"s are worth a couple of minor bugs. This is a pathetic exaggeration and understatement at the same time, I can think of no "Must Have"s and tons of MAJOR bugs. The fact is, most of the program is a giant leap for the development world...IN THE WRONG DIRECTION! Valuable tools were replaced with ineffective alternatives, the compiler is slower and less reliable, sweeping changes by MS developers introduced sweeping bugs into our own code. I am far less than pleased.

I can think of exactly two things that I like about the new IDE. Two, that's it, and they aren't show stoppers. First, I have a little more control over where I dock things and can have certain things pop out when needed and hide the rest of the time (like the output window.) Second, I can see the content of Unicode strings in the debugger and can view strings in a large viewer if I want. These are the only two features that have pleased me. The rest of this buggy mess has wasted easily a hundred hours of my time and consequentially thousands of my employer's dollars.

Anyone care to slam the 100 estimate? sit down and think it out. How much time do you spend compiling in six months? Think carefully. What if this was twice as fast? It was before upgrading to the great new tool. Now add the wasted time from crashes, less effective tools, and the painful process of making the switch. This is an expensive program to run. I am amazed that anyone does. Perhaps they haven't done the math yet.

Definately a leap in the wrong direction. We spent many man months upgrading to VS 2005. What a huge mistake. The IDE crashes every couple of hours. This is the most unstable product I have ever worked with. While I greatly admire the technical ambitions of VS2005 it has been such a costly exercise that I have to consider the following options:1) Abandoning Microsoft IDEs2) Always waiting a few years before adopting a new MS IDE.3) Spend a few man months rolling back to 2003

Many disgruntled voices are not upset because they thought that the product would not have bugs. They are upset because it represents a new quality control low not only for microsoft but for software developed by any large and reputable software house.

As a business owner I am ultimately driven by my bottom line. Upgrading our core technology to VS2005 was the worst financial decision I have ever made in 6 years of running this business.

Dear all,I just felt compelled to write in because this is the first (and could be last) time I trust Microsoft with my development needs. Ever since installing Visual Studio 2005 on Windows Server 2005, I have experienced errors, bugs, crashes and a whole host of things that just didn't work properly. The worst thing about it though is despite this appalling quality (which I will never suffer again), for every bug report I've taken my time to submit, the response that has come back was 'we will look at including this in the next version of the product' or simply 'the problem could not be replicated - won't fix'. I don't know why I bother. Not only have MS created big problems with this release that they apparently don't want to address, they aren't even sympathetic to the people paying for software that doesn't live up to the job. I think we should all claim a refund and compensation for something 'not suitable for the intended purpose'.

Visual Studio is such a retarded product that it does, indeed, lower the bar to the floor for a competitor to produce a better IDE.

What is an IDE? It is a text editor, a compiler, a debugger host, and an information assistant.

What is Microsoft's IDE, Visual Studio? Who knows? It seems to not want to do anything well but to do everything that no one really wants.

Once again, a bunch of managers needed to produce something into this product to keep their empires going, so they did.

Professional opinion here, not just hype: Visual Studio 2005 is not fit to use. Developers will spend far more time trying to research workarounds than using the product. Developers should stay with Visual Studio 2003. It at least works better than 2005. The extra features in 2005 are useless when compared to the trouble with trying to get the product to work. Notepad is now a more reliable development environment than Visual Studio.

Team Server is losing source code faster than Visual SourceSafe ever thought about. Stay away from it. It even loses its virtual directory mappings causing people to mangle their work.

I could go on for months describing the serious Type 1 bugs in this ALPHA product, but I am not paid by Microsoft to do that.

I am not a paid Microsoft developer or tester and feel insulted when told I should offer up what is wrong and work with Microsoft to fix the problems. At this stage Microsoft knows the bugs. I bet their list known of bugs dwarfs our complaints. How about Microsoft getting busy fixing those bugs and stop letting people pollute the products with their empire building?

Microsoft is circling the drain. This latest batch of released products says that Microsoft is not under adult or professional software engineering supervision. I think this is the last major set of products we'll see. After this, I fully expect many competitors to produced working products, putting Microsoft on the back burner.

P.S. I just spoke with my team leads a few hours ago. We are moving our product back to Visual Studio 2003 as of tomorrow. The bite to do that hopefully will remove the pain of trying to crawl through the mud of 2005.

The show-stopper bugs are killing productivity. We find a major bug every 3-5 days. It has taken on average of 2 days to work around each issue. So, we code for three days then have to resolve Microsoft bugs for two. This has been going on for 11 weeks.

Do the math; we have spent about 22 days wasted on Microsoft bugs in 2005. We estimate that moving back to 2003 will cause a 5-10 day delay to recode from 2005 what isn’t compatible in 2003. Nothing in 2005 is worth the hassles so far encountered. 2003 isn’t exactly bug free but at least we can get to where we need to be.

Disclaimer

These are sole individual personal points-of-view and the posts and comments by the participants in no way represent the official point-of-view of Microsoft or any other organization. This is a discussion to foster debate and by no means an enactment of policy-violation. These posts are provided "as-is" with no warranties and confer no rights. So chill. And think.