Only in Silicon Valley

A few minutes ago, I was sitting in my cube coding away when the girl who sits next to me says “argh, why is Outlook so damn hard do use!” rather loudly.

So I say, “what’s wrong with Outlook?”

Then I hear someone else from 2 cubes over yell, “yeah, what *is* wrong with Outlook? “.

As I peek my head over my cube wall to see who said it, he adds, “you know I designed the latest version of it right? That was my last job. What are you having trouble with?”

Now he’s one of the designers that worked with us on Yahoo! Answers. Pretty cool. Especially because Outlook is one of the MS products that I really like (when it’s not being slow).

5 Responses to “Only in Silicon Valley”

  1. Dan McKinley Says:

    Ask him why the reading pane continuously updates after I open Outlook, downloading all of the images in emails while my spam rules process. The message displayed in the reading pane shouldn’t change while rules are running.

    Also ask him why the process grows to well over a gig if I leave it open more than four or five hours. That’s pretty irritating too.

  2. Udi Says:

    He was the interaction/experience designer. He didn’t handle the implementation. Maybe that’s why he left and came to Yahoo! ;)

  3. Tom Says:

    The reading pane is probably redrawing for all the events that could trigger a redraw as it processes your rules. Clearly that wasn’t the right way to do it. The redraw should only happen after an event is detected that requires the redraw.

    As for why the process gets so big, I actually did work on this… more specifically I managed the process by which we got the number of crashes in the product down by 90%. During that process we also got rid of about half of the hangs and heap corruptions, many of which co-occured with memory leaks. Now to catch memory leaks in the act is pretty difficult, usually you need people to be running a special heap/stack tool, and it slows down the machine considerably to do so.

    Testers were able to do this to an extent, but it was impossible to run this against all possible configurations (esp. taking into account 3rd party add-ins which often cause memory leaks).

    Anyhow, if the leak causes a crash, then you can trace some potential fixes based on looking up the bucket number under the crash event in the event viewer. If you have 3rd party add-ins, try uninstalling them to see if you can isolate one of them as the cause. Also try to install the latest office service pack. If those things don’t work, then there’s not much else to do… sorry about that.

  4. Udi Says:

    Thanks Tom!

  5. Dan McKinley Says:

    I eventually used LeakDiag on it myself, and determined that Google desktop search is the problem. Unfortunately, that’s way too useful to uninstall. At any event, not Microsoft’s fault.