In the 90’s Bare Bones Software released a text editor called BBEdit with the tagline “It Doesn’t Suck.” It retains the tagline to this day. Truly brilliant marketing. Who’s their market? Programmers.

Programmers are pessimistic and sarcastic lot. The vast majority will tell you about a hundred things that suck for every one thing that doesn’t. The highest praise a programmer will give a product is, “it doesn’t suck.”

Pessimist programmers are in good company. I’ve read various reports saying the vast majority of projects fail. 80 or 90 percent. Adding insult to injury, it’s not the good 10 or 20 percent that succeed, it’s some hodgepodge of good and bad. It almost seems that bland to downright crappy products are more successful, on average, than really good ones. When a programmer says such-and-such sucks, chances are he’s right.

The Easy Way Out

I can’t explain the origin of this phenomenon, but it’s part of the culture. As I entered industry, I joined in the din. About a year later, my manager said to me, “being a pessimist is the easiest thing in the world. It’s the easy way out. It’s far harder to be an optimist.” Those words—and that challenge—changed my tone and my career.

Assuming that 80% of projects fail and let’s assume that half of the successful ones are mediocre, it’s not rocket science to say something sucks and be right. The gambler would simply say everything sucks. But here’s the problem: you don’t win anything for picking losers.

Let’s be more specific, let’s look at your project. Does it suck? If you think so, what do you think the chances are that it’ll turn out great by accident? Not likely. In assuming your product sucks or will fail, you create a self-fulfilling prophecy. Products are a reflection of the people that make them, so your assumption of suckitude will both show through in the product and reflect on you. Do you suck?

The Other Hand

If, on the other hand, you set out to make a really awesome product and assume it’ll succeed, you just might be right. How cool would that be? And if it’s a flaming wipe-out, so what? Assuming you’ve been collecting a paycheck, you haven’t lost much. Personally, I’d rather collect a paycheck and go for awesome than collect a paycheck and go for mediocre.

The team at Apple that made Macintosh would say that Steve Jobs projected a “reality distortion field” wherever he went. Steve believed completely that Macintosh would change the world and anybody thinking otherwise was a fool. The team got sucked in and believed it, too.

I was sucked into a “second generation” reality distortion field at General Magic, founded by two of the key Macintosh creators. But here’s the thing: I knew it going in. My manager warned me on my first day, “this is not the real world.” But that was fine by me. I was twenty years old, single, and at the coolest startup in Silicon Valley. Bring on the reality distortion—that’s what I was there for.

Turns out General Magic blew a crater in the ground, spending several hundred million dollars and making just about zero back. Failure? Oh yes, absolutely. And I don’t regret it a bit.

The Nature of Failure

When someone asserts that 80-90% of projects fail, you must ask: exactly what do you mean by “fail?” Projects can fail in any number of ways, let me count just a few:

  • Project champions can’t get any backing, project dies as an idea before it makes any progress. That means lost time, but on the plus side the idea may take life in a different form at a later date. (The project I’m currently leading is one of those.)

  • Project gets backing but gets axed during development. Maybe it lost funding, maybe the team blew the schedule by 300%, maybe the company decided to change course. Well, the project’s death didn’t kill you, so brush it off and take a swing at the next one.

  • Project results in completed product, nobody buys it. Could be a product management failure (no market) or an engineering failure (built the wrong thing). Either way, you got to take a project from concept to delivery. Not to mention collect a paycheck. Learn from that experience and get ready for the next.

  • Completed product blows up on the pad. Hopefully in a figurative manner. Maybe it was rampant product defects or perhaps lack of scalability to real-world demand. Work like hell to learn from your mistakes and fix them before the customers walk away. Chances are you’ll be a vastly better programmer afterward.

  • Product is successful for a while, dies off after a couple years. More likely than not, this is a product management failure. You can chalk up your contribution as a win. Go for another (programming) win on the next.

  • Product is successful, company spending goes hog-wild and drives itself to fiscal ruin. In Silicon Valley you could always tell when a company was just about to implode: right when they built their shiny new headquarters building. That meant they had revenue but were outspending it. Not engineering’s fault. Enjoy the nice office and the cappuccino maker before the company goes under.

The common theme here is you can claim success in a lot of scenarios that others call failure. You might have done a kick-ass job, and if so, give yourself credit. Mark it as a win in your book and keep going.

Pessimism Doesn’t Always Suck

While I’ve been rather down on pessimism, let me include this caveat: everyone’s got to vent steam sometime. Some things do suck and you’ve got to say so. Just pick a private forum for it. Pick a buddy or two and preface your complaints with “I’ve just got to vent about [whatever].” I specifically recommend do not vent in email—those have a nasty habit of getting forwarded to just the wrong person. Vent face to face. And when you’re done, close the steam valve and twist the awesome dial back to eleven.


Really enjoying your chapters...and I'm not even close to being a programmer...wishing you all the best on this project...and, may I say, I may have to use your great phrase -- "your assumption of suckitude..." LOL (we have pessimists in finance too!)

Post a comment