Larry says “it’s my bug”

Failing miserably in front of the world is what CEOs are afraid of, when it comes to blogs and video blogging.

I see the blog moving toward a web conferencing platform, not static text posts, but podcasts and video.

But CEOs must be brave enough to go ahead and make some public mistakes as they experiment in the new media.

If you fail, but were trying to connect with your constituents, your stakeholders, your customers, I think the public will not only be forgiving, but you will increase your humanity, your credibility, tear down the wall of hierarchy and elitism, ala naked conversations.

Yah just gotta love the stock 'lie-and-say-whatever-fits-the-mood' Wagged PR response: 'ambient noise', that in a silent room, when even Larry saying it be an incorrect calculation and concurrency timing issue, a real bug.

the bug was fixed on more recent Vista builds than the one they were using for the demo

Ummmmm, here's a stupid question, if this was a known bug, and so easily deconstructed, why not use the FIXED code for demos?

"Yah just gotta love the stock ‘lie-and-say-whatever-fits-the-mood’ Wagged PR response: ‘ambient noise’, that in a silent room, when even Larry saying it be an incorrect calculation and concurrency timing issue, a real bug."

Did you use the Vista speech recognition engine to enter that sentence?

Not quite, but here's my take... :)

Let's set Wagged PR response: "ambient noise", so double delete the killer bug reports, select all "silent room", double the.

If you look at the video, the "delete" and "select all" commands were recognized but the speech recognition engine didn't execute them.

Good on Larry for being man enough to stand up and take the responsibility for this.

This was one of the things that really annoys me with aspects of Microsoft - the excuse layer. I particularly recall the Sidebar gadget guys who hid behind their PM and his pitiful excuses when they admitted the Windows Sidebar wouldn't support WPF. A true professional can admit when they cock up and have the gumption to set out to fix it.

Christopher, there were good reasons for why they were running an older Vista build, as I said - there were a number of other mitigating factors that were involved.

All of those mitigating factors together MIGHT have been enough to tank the demo, but there's no question that the audio bug overwhelmed most of them.

There's no point in playing the "blame game". There were lots of things that could have been done to mitigate the bug, but it doesn't matter.

So I guess now Scoble is going to tell us that keyboards are outdated.

:)

Yeah, I've had that happen. Customer was doing a demo of my app for their users and wanted me there. Not sure why I needed to be there -- it was a fairly basic introduction to the app, but I guess they thought one of the users might have a technical question. The app was pretty robust, but there was one reported bug that I wasn't able to duplicate, so of course I thought, "Well that's the only thing that could possibly go wrong..."

And a tiny little voice saying, "It's a demo. Of course it's going to blow up. Demos are like holding a metal rod above your head while standing in an open field during a thunderstorm and screaming, 'HIT ME!!! HIT MEEEEEEE!!!'"

Demo day arrives; I'm introduced as the developer. I take my seat wayyyy in the back of the room. Pay no attention to me. Nothing to see here. Move along.

Customer starts demo, logs in, app throws spectacular ASP .NET error page.

Time slows down. Tick.

Everyone in the room slowly turns to look at ME. Tick... tick...

Kind of expected to wake up at that point, to sit bolt upright in bed and exclaim, "Man! That was a horrible dream! Only that didn't happen.

At some point the "oh crap" timer expired, and I managed to make some helpful suggestion, like closing all the browser windows and starting over again. (Which is one notch above saying, "Did you try rebooting?")

Everything went perfectly after that.

(Later, I discovered it was a side effect of the demo account we were using, plus lack of exception handling, which made me feel a tiny bit better that it was only 82% boneheaded and not 100% boneheaded on my part.)

It was not a fun thing, but I can recommend the experience, because it

1) makes you more determined to write better code and not repeat the experience,

2) makes you less afraid of failing, when you find out that the world actually doesn't end after all, and

3) is humbling.

I think it's what they used to call a "character-building" experience, back in the days of yore, when people actually took responsibiility for their failures. :-)

Larry... uh... this Fin Anaylst Meeting wasn't a surprise, was it? I mean, surely this demo had to have been rehearsed numerous times,right? Surely Microsoft doesn't go into such an important meeting not having tested their demo in the enviroment in which it will be run live, does it? If not, that says quite a bit about the test criteria.

Excuses excuses. When the program printed "select all" instead of executing it, it could not be attributed to echo.

When the program printed "delete" 5 seconds after the word was uttered, that cannot be attributed to echo.

This software is not "beta" or "temperamental". It's just crap. Microsoft always overhypes and underdelivers 99% of the time. You can't blame a track record like that on any single overworked programmer taking time to fix a single random bug.

In other news, Ten-year-old Apple Newton beats latest Windows UMPC:
http://crave.cnet.co.uk/handhelds/0,39029444,49...

If you grew up working on a Unix machine like I did, working in Terminal.app isn’t just a walk down memory lane, it’s more productive.
Pak Car

but it doesn’t matter...

It doesn't matter? What? Yes it does. And not so much a 'blame game' as more finding out what really went wrong and how to fix it, and prevent such from ever happening again. Blame-gaming oft times never gets to the root of the problem, easier to slice heads, than to deal with systematic fundamental problems.

It matters, as a look back can help fix things. Other companies get sued when they ignore known defects. In the military, they pour over battlefield analysis, almost down to the molecule.

The customer ain't gonna care a simple microscopic iota about all the "taking responsibility character-building" experiences. So save that justifcational psychobabble for internal process analysis, just make it work.

Cider, what are you talking about?
I see Microsoft devs stepping up to take responsibility for bugs/problems all the time, since so many Microsoft devs have blogs.

I've *never* seen an Apple dev take responsibilty for anything at all, and no it's not because Apple software is perfect, I'm a Mac user, so I know.
And I just use Apple as an example, since Apple is portrayed as "perfect", but I rarely see any dev publicly taking personal responsibility for a bug. When I was a programmer, I certainly never did, nor did any of my coworkers. But I see Microsoft devs (the ones that have blogs) do it often.