The Only Truly Failed Project

Do you remember Microsoft Bob? If you do, you probably remember it as an intensely marketed but laughable failure – what some call the "number one flop" at Microsoft.

This is a companion discussion topic for the original blog entry at:

Like A.J., my mom also loved Bob, and mourned when she couldn’t use it any more.

1 Like

Bob might have been Microsoft’s greatest failure, but Microsoft Plus was their 2nd … oh, wait, I forgot about ME. Silly me.

ARGHHHH!!! All of my failures are in production. None of them were canceled when they should have been.

Bob was pretty bad.

I’ll have to check out Tilt. Sounds interesting.

+1. Indeed. Without doubt, this is one of the best entries on this blog.

btw, MS Bob runs on XP! give it a try :slight_smile:

Reminds me of this quote found in “The Drunkard’s Walk”, attributed to Thomas Watson:
“If you want to succeed, double your failure rate”.
Failure for the Win!

“The only truly failed project is the one where you didn’t learn anything along the way.”

So true. Once worked on a project that was obviously heading for failure from an early age. I kept pressing that when the project ended there needed to be a post-mortem review, find out why it failed, what could have been done to avoid problems and, what could be learned from the experience. Of course, none of this happened, the project was quietly forgotten about as if it had never existed. I think lessons are not learned if nobody admits when there’s been a problem.

“Success has a thousand parents, failure is an orphan.”

Microsoft’s real genius has always been their willingness to fail. They fail and fail and fail (Windows 1, 2, 3 … Word 1, 2, 3 …) and keep failing until they get something that people buy. Whether you like them or loath them, Microsoft has succeeded by not giving up. I admire that.

I love the quote “Fail faster, succeed sooner”, attributed to David Kelley, founder of IDEO. As long as the mistakes aren’t repeated, failure can be a very efficient way to gain experience quickly - while the timid pick their way thru the minefield afraid of any setbacks, the bold go full steam ahead, learning and adapting from each setback.

I can’t agree more with this, every days a school day for programmers.
Even if your project doesn’t fail, mistakes WILL be made and hopefully learnt from fixed and improved.

If a programmer doesn’t accept their failures and learn from them you probably wouldn’t enjoy working with them.

You claim “a practical-minded obsession with the possibility and the consequences of failure” is needed for success. I say that leads to inevitable failure, as you are written off as a chronic worrier and general killjoy every time you anticipate a risk and try to do something to overcome it.

In the current mindset of the masses, we are required to be delusionally happy and impossibly confident, right up to the moment of easily avoidable disaster. And then, we are required to be convenient scapegoats because, at some time, we weren’t quite delusionally happy enough and our negativity somehow must have caused the failure. After all, how could a positive mental attitude (ie a refusal to consider possible problems and look for solutions) cause failure?

Our one time assistant provost held a meeting on improving student retention (we’re a private institute, so students = $, and retained students cost a lot less than recruited ones).

Anyhow, she said our goal should be “to ensure our students can’t fail.”

To which I replied, “I see it as essential that our students fail, and our goal is to help them recover and learn from failure.”

I know that in my own professional career (in industry and academia), I’ve learned a hell of a lot more from my failures than I have from my successes. Success may just reinforce your current ways of doing things - and some of these ways are most assuredly poor. Failure makes you reflect, starting from first principles.

A great, thought-provoking entry, but in addition to learning from each project one needs to be able to concisely describe what they learned. Even better if they can write it down, like in an email to themselves. Not only helpful for interviews but also as a periodic reminder.

I also believe it’s important to look at each project and ask what you would’ve done different, especially where you wish you had acted sooner. Holds true for glorious failures and quiet successes.

Without the cancellation of the Arrow NASA would’ve been very different.


The real problem, in my opinion, are companies and people who don’t learn from their mistakes. Even though they see what went wrong, they do it again and again. I’ve ranted lately about focusing just on revenue, not on software itself on my blog which for me is a major mistake. I’m currently working on a project that is an epic fail, however I hope that it would be a lesson not only for developers who now work with it, but also for management.


I think Big Enterprise CEO are a bit to loving themselves. Why do you teache history at school, so that next generation dont make the same mistakes then befor, but in an enterprise the big CEO just say he did that wrong and dont watch his on front yard…

You, sir, have a pinball addiction :slight_smile:

1 Like

Yeah – on a project now and there’s one person at the client office who just hates having to learn something new … and so she’s done nothing but try and derail things and create problems where there are none.

She’s largely succeeded, but, at least, we’ve got lots of reusable stuff and lessons to file away for ‘the next one’.

Ah well.