This is a strange one

[George Hester]

http://support.microsoft.com/default.aspx?scid=kb;en-us;322632

Why was this never fixed? Did Microsoft lose interest in making
functionaing software?

 

[Dave]

why would they fix an obsolete product?

 

[George Hester]

Uhm Dave it didnt't work before it became obsolete now did it? Come'on man
think. I actually found a fix for it. Different then what they have there.

--
George Hester
_________________________________

why would they fix an obsolete product?

 

[Dave]

no, but so what. its replacement product doesn't have the same bug, so
essentially its fixed. should they go back and fix win 3.1 bugs that are
outstanding just to remove the kb item? or to keep those backwards users
who refuse to upgrade happy??

Uhm Dave it didnt't work before it became obsolete now did it? Come'on
man
think. I actually found a fix for it. Different then what they have
there.

 

[George Hester]

No they should have fixed it at the time it was being used. It's not such a
hard concept. What do you mean its "replacement product." What are ou
talking about? Did they replace it with a MOD2000 that worked? I didn't
know that that's a new one on me.

Should they go back and fix Win 3.1 bugs? No they should have fixed them at
the time it was used. If they cannot then they make a new product and there
we are. But this MOD2000 issue I would say is not really a bug. It is just
sloppy engineering sloppy. Can you imagine what the developer communinity
must have thought purchasing a product at that cost ($800.00) and finding
immediately upon installtion they were faced with a error? I'm surprised
Microsoft had the fortitude to release such a mistake. What does that say
about future products?

 

[Dave]

office xp developer replaced 2000 developer years ago, or haven't you been
keeping up?

 

[George Hester]

What's your point?

 

[Dave]

that office xp has replaced office 2000, so the office 2000 developer is no
longer a current product, so why should they go back and fix it any more
than they should go back and fix win 3.1? and now of course it is another
generation out of date with office 2003 out.

 

[John R. Durant [MSFT]]

Guys! Let's all take a deep breath, and maybe I can help.

George, I hear you. It's frustrating when things don't work as expected.
Even though MOD has been transcended, as Dave points out, a lot of companies
are still using it because they paid good money for it, and they want their
value out of it.

Here at Microsoft, like any software company, there are challenges. For
every product/feature there are program managers, developers, and testers.
There are other players, but these are the big three. We have to budget how
we spend their time. As we approach the release of a new software version,
we see bugs come through, and we triage them every morning. Which ones are
must-fix? Which ones appear in uncommon scenarios? More questions arise, but
at the end of every triage meeting (mine starts in a few minutes for Visual
Studio 2005 Tools for the Microsoft Office System), we need to decide
whether we are going to take the bug and fix it or take other action. As the
product gets closer to release, the bar for what gets fixed is raised higher
and higher. This is because a single modification usually affects other
features owned by other teams, and the trickle down effect can be
substantial. If the software is completely broken, then, even with the bar
very high, we'll take it and fix it. If there is a work-around or a
technique to make it work, we'll add it to documentation and so forth. After
the software releases, we get customer feedback, and we triage that. This
leads to service releases or features in later versions. While we are
working on that, we are already taking on the full product cycle for the
next version of the software we just released, and so it goes around and
around.

This is not meant to excuse mistakes, but to show you how things work.
Despite what people sometimes think, we do not have endless resources and
time. We have to make educated decisions, and sometimes those are hard
decisions that can cause a little frustration, but in general, I think we
get it very right. Our customer satisfaction is going up, because we have
made a company-wide effort to LISTEN. I think we are doing this now more
than ever (like my listening to this thread on the NG!).

I hope you take a look at VSTO 2005. It's great stuff, and we worked very
hard on it. I am confident in what we deliver to customers, because we want
to make customers as happy as we can.

HTH!

--
John R. Durant [MSFT]

blog: http://blogs.msdn.com/johnrdurant

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[George Hester]

I always knew that John. Microsoft is a very concientious corporation. I'd
be the first to admit that. That's why I found it so surprising such a
simple issue as this one was allowed to persist. Was this "bug" as hard to
fix as I get the impression it was or were so many MOD2000 packages made
that letting anyone know of the issue there besides the Knowledge Base would
have been too costly? Well thanks for your input you addressed my concerns.

--
George Hester
_________________________________

Guys! Let's all take a deep breath, and maybe I can help.

George, I hear you. It's frustrating when things don't work as expected.
Even though MOD has been transcended, as Dave points out, a lot of companies
are still using it because they paid good money for it, and they want their
value out of it.

Here at Microsoft, like any software company, there are challenges. For
every product/feature there are program managers, developers, and testers.
There are other players, but these are the big three. We have to budget how
we spend their time. As we approach the release of a new software version,
we see bugs come through, and we triage them every morning. Which ones are
must-fix? Which ones appear in uncommon scenarios? More questions arise, but
at the end of every triage meeting (mine starts in a few minutes for Visual
Studio 2005 Tools for the Microsoft Office System), we need to decide
whether we are going to take the bug and fix it or take other action. As the
product gets closer to release, the bar for what gets fixed is raised higher
and higher. This is because a single modification usually affects other
features owned by other teams, and the trickle down effect can be
substantial. If the software is completely broken, then, even with the bar
very high, we'll take it and fix it. If there is a work-around or a
technique to make it work, we'll add it to documentation and so forth. After
the software releases, we get customer feedback, and we triage that. This
leads to service releases or features in later versions. While we are
working on that, we are already taking on the full product cycle for the
next version of the software we just released, and so it goes around and
around.

This is not meant to excuse mistakes, but to show you how things work.
Despite what people sometimes think, we do not have endless resources and
time. We have to make educated decisions, and sometimes those are hard
decisions that can cause a little frustration, but in general, I think we
get it very right. Our customer satisfaction is going up, because we have
made a company-wide effort to LISTEN. I think we are doing this now more
than ever (like my listening to this thread on the NG!).

I hope you take a look at VSTO 2005. It's great stuff, and we worked very
hard on it. I am confident in what we deliver to customers, because we want
to make customers as happy as we can.

HTH!

--
John R. Durant [MSFT]

blog: http://blogs.msdn.com/johnrdurant

This posting is provided "AS IS" with no warranties, and confers no rights.