First let me say that if I sound like an Outlook noob, its because I
am. Until earlier this year, I was using Eudora as I had been for a
decade or so, but of course Qualcomm screwed the pooch, and I already
owned Office 2007, and I am familiar with Outlook from work (and like
the interface BTW) so I thought why not. For the most part I have
been pleased. But when you read the rest of this please understand
that e-mail, as well as my ability to search and retrieve particular
messages, is the single most critical part of my computing experience.
A meltdown has personal and financial consequences that would be
difficult to describe.
On Christmas (Dec 25th to be exact) I noticed Outlook 2007 would not
start, it would hang at the start screen. I'm using Windows 7 64-bit,
all the latest and greatest patches for both the OS and Office. One
of the first things I did was look at the updates history, what might
have changed that day that could affect it? All I saw was related to
Windows Defender -- I'm not even sure how that is on my machine
anymore or how it relates to Security Essentials, I just know its on
my PC and it came down through recommended Windows Updates. So I
tried disabling Windows Defender, which made no difference.
It would start fine enough in Safemode after I went to the
incovenience of manually creating a shortcut to do so. CTRL-clicking
on the Outlook icon in my programs list didn't work. So naturally
based on search engine results, I tried the typical things like
disabling add-ons, disabling virus protection etc.
After a good 4 to 5 hour struggle, lots of searching and
experimentation, it turns out that my OUTCMD.DAT file was corrupt.
This was not easy information to come upon, using either my preferred
search engine (bing) or its alternative (google).
So what I would like to ask of the Outlook team.... and I'm not
talking about the actual developers here, because I know the real
decisions are made by management..... is, how in the world can you
feel good about yourselves as owners of an application as important as
Outlook, yet not take the time to detect corruption of OUTCMD.DAT, and
at least prevent the CPU from pegging and the processing going
non-responsive? As I said, I'm a developer and my first language was
assembly.. I know shit about bits and bytes that 99% of the offshored
inbred programmer morons will never figure out. To be in charge of an
application this significant, and not be able to programmatically
detect corruption of a file which as far as I can tell retains toolbar
command settings is completely unfathomable, particularly considering
how some people plan to use their e-mail client as their primary
knowledgebase.
Well there ya go, my opinion in a nutshell. I make the bulk of my
current living off MS technology (including .Net, MFC and ATL), and in
the past I always regarded the Microsoft haters as those who were too
lazy or stupid to figure out the simple stuff, but this goes above and
beyond poor software. Before I found the fix, I came very close to
just finding a new e-mail client and finding another way to salvage
the .PST file contents even if I hate to write it myself. If you
cannot create an e-mail client that works, and repairs itself or gives
the user SOME INKLING as to how to fix when things go wrong, it does
not bode well for the future of your company. All it would take is a
simple popup to tell me which file to delete and how to create, yet
instead you have wasted half a day of my life. That I wont forget.
> [a novel...]
Could you explain the problem you have with Outlook sententiously? I
don't think that anybody here will read your posting entirely ;-).
--
Best Regards
Christian Goeller
MVP - MS Outlook
http://www.outlookfaq.net
>Jay Hornsman, you wrote on Mon, 28 Dec 2009 02:12:04 -0500:
>
>> [a novel...]
>
>Could you explain the problem you have with Outlook sententiously? I
>don't think that anybody here will read your posting entirely ;-).
It was not intended for lazy or slow readers in the first place, so
the filter is working. And it wasn't something that requires a
response, since it is not only the problem but the solution.
--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com/
Outlook Tips by email:
mailto:dailytips-sub...@lists.outlooktips.net
EMO - a weekly newsletter about Outlook and Exchange:
mailto:EMO-NEWSLETTER-S...@PEACH.EASE.LSOFT.COM
Poll: What version of Outlook do you use?
http://forums.slipstick.com/showthread.php?t=27072
"Jay Hornsman" <Horn...@invalidmail.com> wrote in message
news:c9phj5h0q3vq2kr3m...@4ax.com...
>While you don't want a reply, I will comment for the benefit of others who
>find the long missive... a corrupt outcmd.dat is rare (and will become rarer
>as outlook 2010 doesn't use it). It happens most often during upgrades -
>either in-place upgrading from an older version of outlook, or if easy
>transfer is used to move outlook to a new machine. It is one of the 4 files
>that doesn't upgrade from Outlook 2003 to 2007 well.
I didn't find it to be particularly rare, bing or google around a bit
and I think you'll find lots of folks have had the problem. I also
did not upgrade, this is the first install of Outlook I've ever had on
my home system, and it's been working pretty well for the past few
months. As I mentioned in my long missive, I went from being a long
time user of Eudora to this.
The real reason for the original post is to make the point that from a
software engineering standpoint, it is unexcusable to have an entire
application simply freeze up; completely locking the user out of an
application as critical (to most) as their e-mail client.
Particularly since outcmd.dat is apparently an optional file of little
consequence if deleted and recreated. All it takes is a little
defensive code to detect when something is out of whack with
outcmd.dat, and boycott loading that particular file but allowing the
user to continue so they can get to their e-mail. I think we could
all agree this seems a bit more elegant than resulting in a frozen
splash screen and a process that sits there and burns CPU cycles doing
nothing.
There are other files that get corrupted more often - some are replaced by
outlook automatically, others are not. Users do not like it when outlook
deletes customizations, even if the file is bad. If they replace it
themselves, they can see that it really was corrupt and not just outlook
deleting files willynilly.
--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com/
Outlook Tips by email:
mailto:dailytips-sub...@lists.outlooktips.net
EMO - a weekly newsletter about Outlook and Exchange:
mailto:EMO-NEWSLETTER-S...@PEACH.EASE.LSOFT.COM
Poll: What version of Outlook do you use?
http://forums.slipstick.com/showthread.php?t=27072
"Jay Hornsman" <Horn...@invalidmail.com> wrote in message
news:ee5ij55el5bq2ih9b...@4ax.com...
>outcmd.dat is the toolbar customization file. It's only created when you
>customize a toolbar in Outlook. While outlook will recreate it, its not
>inconsequential or of little value to most people who have one.
>
>There are other files that get corrupted more often - some are replaced by
>outlook automatically, others are not. Users do not like it when outlook
>deletes customizations, even if the file is bad. If they replace it
>themselves, they can see that it really was corrupt and not just outlook
>deleting files willynilly.
But would you agree that a simple pop-up letting the user know the
file is bad, and either giving them the choice to continue, or the
choice to exit and go fix it themselves, or the choice to erase it,
would be better development decision than to simply let the process
freeze up, requiring manual termination of the process and a lot of
head scratching wondering what went wrong? A freeze on start-up that
does not occur in safe mode first sends one down the path of looking
at add-ins, antivirus issues, recent windows updates and such. There
is no good excuse for just leaving them guessing due to a corrupt file
which is really inconsequential in itself anyway.
--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com/
Outlook Tips by email:
mailto:dailytips-sub...@lists.outlooktips.net
EMO - a weekly newsletter about Outlook and Exchange:
mailto:EMO-NEWSLETTER-S...@PEACH.EASE.LSOFT.COM
Poll: What version of Outlook do you use?
http://forums.slipstick.com/showthread.php?t=27072
"Jay Hornsman" <Horn...@invalidmail.com> wrote in message
news:mt9ij5tqe2ffhqag4...@4ax.com...
>if they could detect that it's the outcmd and not the navpane or to-do bar
>fail causing the problem, yes. But they often can't detect the cause of
>problems.
With all due respect, anyone who believes that has never written a
software application in their lives.
I can believe MS support might not know which one is causing the
problem (although, I believe the command line switches can isolate it
further than the scenario you describe above). But don't spend one
second convincing yourself that the actual developers cannot detect
the cause, with a debugger they can see the exact line of code causing
the issue.
--
Diane Poremsky [MVP - Outlook]
Outlook Tips: http://www.outlook-tips.net/
Outlook & Exchange Solutions Center: http://www.slipstick.com/
Outlook Tips by email:
mailto:dailytips-sub...@lists.outlooktips.net
EMO - a weekly newsletter about Outlook and Exchange:
mailto:EMO-NEWSLETTER-S...@PEACH.EASE.LSOFT.COM
Poll: What version of Outlook do you use?
http://forums.slipstick.com/showthread.php?t=27072
"Jay Hornsman" <Horn...@invalidmail.com> wrote in message
news:1uhij5tndsnqsc3c8...@4ax.com...
>the "cost" in speed and resources is too high and the
>benefit too low.
That is short-term management think, and the primary cause of poor
software quality. "It's too expensive to make an app as important as
a widely used e-mail client reliable"; this mentality has a much
greater long term cost, as users get fed up with the software and
switch to another vendor offering. I would agree that not every bug
is worth chasing down, but e-mail is critical for most users, and if
it is not rock solid (or at least degrade gracefully), users will
simply seek alternatives. Microsoft cannot afford much more lost
goodwill due to poor software quality, and if they continue to employ
management that relies more heavily on "business metrics" and pretty
charts and graphs to guide their direction, their reign will be short
lived. That is a cost that a software vendor cannot afford. Do it
right the first time and the health of the company will remain strong.
Google, Apple and others have been eroding MS marketshare in every
category for some time now, and it is up to MS to re-think the cost of
quality versus the cost of low quality, or the competitors will simply
keep coming until there's nothing left.
>Crashes can send data back to Microsoft (if you allow) so
>they can analyze and fix the problem but hangs don't generate doc watson
>files.
If they felt the cost was too high to fix it the first time, why would
they invest time to fix it after the fact? It is a known software
engineering fact that the least expensive time to fix a bug is in
early development and testing, and the cost skyrockets exponentially
after the product has shipped or otherwise late in the lifecycle.
I've never received a followup from MS that said "hey we fixed your
bug, just grab the latest update". I agree they can fix the problem
but for reasons mentioned above they often don't.
Outlook is very stable and reliable. It has its share of bugs, but millions
use it daily and very few have problems with it.
The primary cause of bugs in any application is short dev cycles and reusing
the old code - no one codes new versions from the ground up (it would be an
impossible task). The software needs to run on a variety of hardware,
operating systems, and coexist with all kinds of different software, some of
which it interacts with (like antivirus and browsers.) BTW - antivirus is a
frequent cause of file corruption.
> If they felt the cost was too high to fix it the first time, why would
> they invest time to fix it after the fact? It is a known software
> engineering fact that the least expensive time to fix a bug is in
> early development and testing, and the cost skyrockets exponentially
> after the product has shipped or otherwise late in the lifecycle.
They fix what they find but many bugs don't show up until the customer does
something specific - maybe uses mail server software that is less popular
and not used by the testers or the user adds 99 exchange mailboxes or pst
files to the profile (something the testers did not try) - both of these
bugs were fixed with the help of watson reports. Some bugs aren't outlook's
problem - they are caused by other programs the user installs (or
uninstalls), including firefox and chrome (http://slipstick.me/restrict)
> I've never received a followup from MS that said "hey we fixed your
> bug, just grab the latest update". I agree they can fix the problem
> but for reasons mentioned above they often don't.
Me neither. They don't send replies to anyone because the reports are
anonymous. They don't know who sends what. Occasionally when I complain
about a crash my contact will ask for the "bucket number" so he can look it
up - that's the only way to identify the watson report as mine.
Have you considered applying for a job with them? I'm sure they could use
your programming knowledge and skills.
>> That is short-term management think, and the primary cause of poor
>> software quality. "It's too expensive to make an app as important as
>> a widely used e-mail client reliable"; this mentality has a much
>
>Outlook is very stable and reliable. It has its share of bugs, but millions
>use it daily and very few have problems with it.
>
>The primary cause of bugs in any application is short dev cycles and reusing
>the old code
Code re-use is the whole point of modern object-oriented software
development, and helps reduce bugs, not introduce them. You are
correct however in stating that inordinately short dev cycles lead to
a higher bug count ("inordinately" being the operative word here).
"Old" but fully reusable (i.e. still relevant) code is the holy grail
that good software engineers strive for. Something that works should
not be changed without good reasons. If it still works, there is
little reason to re-write it UNLESS it was poorly designed and NOT
re-usable.
That is where the art and science of refactoring comes in.
>- no one codes new versions from the ground up (it would be an
>impossible task).
I would never suggest that Outlook needs to be re-written from the
ground up to solve this sort of quality issue, but to say it's an
impossible task is overkill.
>The software needs to run on a variety of hardware,
>operating systems, and coexist with all kinds of different software, some of
>which it interacts with (like antivirus and browsers.) BTW - antivirus is a
>frequent cause of file corruption.
I understand the challenges of the OS running on different hardware,
but we are now blurring systems development with application
development. The e-mail client does not need to care about what
hardware it runs on as long as it is properly written. It only needs
to interact with layers on top of the operating system. The
particular bug I mentioned has nothing to with hardware, the OS
itself, the networking stack, etc. It does relate to the file system
if you want to stretch it a bit, but since Microsoft owns the file
system there are no opportunities for excuses there, and I seriously
doubt it would behave differently if I were using anything but NTFS.
In this particular case we are talking about opening a file and
reading it to perform some action, and if the integrity of that
operation is compromised, degrading gracefully rather than leaving a
process running and eating CPU but not responding.
Also, the only reason they need to worry about different operating
systems is the fact that so many users are still on XP. Had they not
rushed Vista out the door and eroded confidence in the quality of the
OS, most users would be using nothing but Vista and Windows7 at this
point, which are similar enough that OS differences would be
irrelevant. That is an example of what I spoke of before about
short-term cost savings leading to a longer-term cost. Because they
rushed out Vista thinking "we can address it in a patch", or "that bug
is too expensive to fix", they now find them in a position to support
an aging operating system, which requires a lot of development and
testing resources to support. Taking the time to do it right the
first time always ends up saving money in software development.
>> If they felt the cost was too high to fix it the first time, why would
>> they invest time to fix it after the fact? It is a known software
>> engineering fact that the least expensive time to fix a bug is in
>> early development and testing, and the cost skyrockets exponentially
>> after the product has shipped or otherwise late in the lifecycle.
>
>They fix what they find but many bugs don't show up until the customer does
>something specific - maybe uses mail server software that is less popular
>and not used by the testers or the user adds 99 exchange mailboxes or pst
>files to the profile (something the testers did not try) - both of these
>bugs were fixed with the help of watson reports.
I'm no stranger to unsupported edge cases that can result in bugs, and
I don't expect any application to work perfectly in every obscure
case. But to respond to examples, for obscure mail server software,
the client should degrade gracefully with a message saying there is a
problem communicating with the server or something similar. In the
case of 99 mailboxes, the developers should be writing repeatable unit
tests which stress-test the code (they should be able to hit a button
and automatically generate thousands of mailboxes, so that they
understand the upper limit and can document it as a known limitation
(or better yet, have it degrade gracefully when the threashold is
reached). With automated unit tests, they should be able to
continually run the same tests with a click of the button, so that if
there is a change to the code in a future release, they can ensure
that backward compatibilty has not been broken. Thus, the cited
examples are still not an excuse for the application process to go
unresponsive and are relatively easy to address before they impact the
customer.
>Some bugs aren't outlook's
>problem - they are caused by other programs the user installs (or
>uninstalls), including firefox and chrome (http://slipstick.me/restrict)
It certainly is Outlooks problem (perhaps combined with Windows
problems) that it allows these applications to create conflicts when
installed or uninstalled. Other applications should not be allowed to
tamper with system files or settings that Outlook is dependent on.
Again in the case something is out of kilter, Outlook should detect it
and give the user a clue of the nature of the problem.
>> I've never received a followup from MS that said "hey we fixed your
>> bug, just grab the latest update". I agree they can fix the problem
>> but for reasons mentioned above they often don't.
>
>Me neither. They don't send replies to anyone because the reports are
>anonymous. They don't know who sends what. Occasionally when I complain
>about a crash my contact will ask for the "bucket number" so he can look it
>up - that's the only way to identify the watson report as mine.
>
>Have you considered applying for a job with them? I'm sure they could use
>your programming knowledge and skills.
No, I have not considered applying for them. Their standard for
quality is not up to the one I hold myself to, and the management
"rush the software out and let the users find the bugs" mentality
would drive me crazy. Also from a politcal standpoint, I get tired of
seeing them outsource jobs under the premise that "local talent is not
available" when there are plenty of unemployed programmers in the US.
I understand they look at it from the perspective that they can pay
less for overseas labor, but having been involved in many projects
involving outsourcing, I can say that this is often a primary
contributor to the quality problems I've highlighted in this thread,
and has a lot to do with why Microsoft's own products do not
interoperate well together. Again a focus on short-term cost savings
that costs more in the long run.
Currently I still make my living using their development tools,
primarily because they still have the lions share of OS marketshare,
but that is changing and will continue to do so if they do not adopt a
higher focus on quality. Another indication of this is their recent
spates of layoffs; I just hope they can get their act together in
time to save the company as I do have a lot of time invested in the
platform.