Coding Horror: Fail Early, Fail Often

May 01, 2006

Fail Early, Fail Often

Scott Hanselman thinks signing your name with a bunch of certifications is gauche:

If it's silly to suggest putting my SATs on my resume, why is ..
Scott Hanselman, MCSD, MCT, MCP, MC*.*
.. reasonable? Having a cert means you have a capacity to hold lots of technical stuff in your head. Full stop. I propose we sign our names like this:
Scott Hanselman, 11 Successful Large Projects, 3 Open Source Applications, 1 Colossal Failure
Wouldn't that be nice?

I agree. Your credentials should be the sum of the projects you've worked on. But I think Scott has this backwards: you should emphasize the number of failed projects you've worked on.

How do we define "success", anyway? What were the goals? Did the project make money? Did users like the software? Is the software still in use? It's a thorny problem. I used to work in an environment where every project was judged a success. Nobody wanted to own up to the limitations, compromises, and problems in the software they ended up shipping. And the managers in charge of the projects desperately wanted to be perceived as successful. So what we got was the special olympics of software: every project was a winner. The users, on the other hand, were not so lucky.

Success is relative and ephemeral. But failure is a near-constant. If you really want to know if someone is competent at their profession, ask them about their failures. Last year I cited an article on predicting the success or failure of surgeons:

Charles Bosk, a sociologist at the University of Pennsylvania, once conducted a set of interviews with young doctors who had either resigned or been fired from neurosurgery-training programs, in an effort to figure out what separated the unsuccessful surgeons from their successful counterparts.
He concluded that, far more than technical skills or intelligence, what was necessary for success was the sort of attitude that Quest has—a practical-minded obsession with the possibility and the consequences of failure. "When I interviewed the surgeons who were fired, I used to leave the interview shaking," Bosk said. "I would hear these horrible stories about what they did wrong, but the thing was that they didn't know that what they did was wrong. In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, 'Gee, I haven't really had one,' or, 'I've had a couple of bad outcomes but they were due to things outside my control'—invariably those were the worst candidates. And the residents who said, 'I make mistakes all the time. There was this horrible thing that happened just yesterday and here's what it was.' They were the best. They had the ability to rethink everything that they'd done and imagine how they might have done it differently."

The best software developers embrace failure -- in fact, they're obsessed with failure. If you forget how easy it is to make critical mistakes, you're likely to fail. And that should concern you.

Michael Hunter takes this concept one step beyond mere vigilance. He encourages us to fail early and often:

If you're lucky, however, your family encourages you to fail early and often. If you're really lucky your teachers do as well. It takes a lot of courage to fight against this, but the rewards are great. Learning doesn't happen from failure itself but rather from analyzing the failure, making a change, and then trying again. Over time this gives you a deep understanding of the problem domain (be that programming or combining colors or whatever) - you are learning. Exercising your brain is good in its own right ("That which is not exercised atrophies", my trainer likes to say), plus this knowledge improves your chances at functioning successfully in new situations.

I say the more failed projects in your portfolio, the better. If you're not failing some of the time, you're not trying hard enough. You need to overreach to find your limits and grow. But do make sure you fail in spectacular new ways on each subsequent project.

Posted by Jeff Atwood at May 1, 2006 11:59 PM | TrackBack

Comments

"Having a cert means you have a capacity to hold lots of technical stuff in your head."

I think it often also means "I had money to spend on courses and didn't realise I could learn more spending less money just by buying the software and teaching myself" or "my workplace had some leftover budget this year, so I sat through a few courses which I'll never use."

Paul Coddington on May 3, 2006 01:15 AM

 my workplace had some leftover budget this year, so I sat through a few courses which I'll never use."

Someone being victim from a budget cut? :) well I am big failure, I have no cert, but I never really felt I needed one, except I could get paid more and I would probably get more chicks with some form of MCS.*.

But anyway, why not focus on "did you do the job?" and not so much on success/failure?

If I code 24/7 on a project and I accomplish my development goal, but the project is never used, I would of cause be sad. But if I did a good job, I would still be proud of what I did. Yes, you can’t live from bits and bytes, but money and success is not everything. Developers are becoming marketing minded, and in a lot of ways that is a good thing. Call me old fashioned, but I still think developers should focus more on DWords then BuzzWords...

Peter Palludan on May 3, 2006 01:52 AM

Jeff: do you have a quote / edit function ? Was trying to quote the first comment.

Peter Palludan on May 3, 2006 01:53 AM

Jeff... have you been into the sauce?--- if I failed in spectacular new ways on each subsequent project, I wouldn't have a job for long.

Normally, I love your blog... a billion times more than my own. Keep up the good work.

Michael Reinhart on May 3, 2006 05:30 AM

Famous quotations don't teach much but they can remind you of something you've learned and are sometimes good to help point a discussion in a direction. One of my favorite quotes is:

"Good judgment comes from experience, and experience comes from bad judgment." Barry LePatner

Perhaps more in your theme, it could be modified to end, "..comes from LEARNING from bad judgement." Just having bad judgement doesn't help if you don't study the failure and learn from it.

Jim Dodd on May 3, 2006 06:44 AM

There's a big difference between personal failure and project failure. And of course, success and failure can be very subjective.

A recent blog post declares VS 2005 a failure: http://nothing-more.blogspot.com/2006/04/visualstudio-oh-my.html. I disagree. So is it a failure or not?

Consider the scenario where developer is assigned to work on a section of functionality that will not have an impact on the overall success or failure of the overall project because it was over or under architected. Is that project a failure for that developer?

How about project managers who under-bid the amount of time it will take to complete a project? Will they report "1 colossal failure" on their resumes?

Schuyler Colfax on May 3, 2006 07:57 AM

But mistakes aren't failures. For example, in the application that I'm currently working on, we made a number of bad decisions (as in, "God I wish I could do this over") involving requirements gathering, the database schema, and parts of the user interface.
But I'd still count the application as a success. Our users are able to use it to do stuff that they'd given up doing because it had gotten too difficult.
So, I'd ask what was your worst failure, and what was your worst mistake.

And I've also found certifications to be worthless when hiring. Very rarely have I had a person with a certificate be able to answer an interesting technical question. Worse, they often won't even guess.

Mike Swaim on May 3, 2006 08:09 AM

Don't under estimate the power of bullshit on a resume. And Certs are just that. Fluff that impresses managers and gets your resume read. As for failure, its all about risk. I think in general if you (or an orginazation) take big risks you will fail more often. But, your successes will be more spectacular.

Bob on May 3, 2006 10:57 AM

> if I failed in spectacular new ways on each subsequent project, I wouldn't have a job for long.

Statistically speaking, most IT projects are failures, though.

http://www.it-cortex.com/Stat_Failure_Rate.htm

But as Mike points out, we have to distinguish between mistakes and failures.

Jeff Atwood on May 3, 2006 11:22 AM

How's this for irony: the above site fails to work properly in FireFox.

Mozilla on May 3, 2006 01:21 PM

This reminds me of my first big mistake as a professional developer: I released an electronic trading application I wrote without thoroughly testing it. A few minutes before the close, we hit a bug, couldn't cancel the orders and it cost us about $45k. My stomach hit the floor and I thought I would be fired on the spot. (I didn't).

The experience got me obsessed with testing. I wrote test scripts for the application, adding a feature that allowed it to record and playback UI events. I learned how to use a test coverage tool to help me design test cases, and most importantly, I learned how to say "no" to the traders when they pressured my to release before I was ready.

The application turned out to be a big success and helped us make a lot of money (with the $45k loss little more than a rounding error). Years later I was not only able to see the value of the stressful lesson, but also to use it as a great story in interviews.

I only wish I'd made more mistakes that had such a positive effect on the way I work.

David Avraamides on May 3, 2006 06:52 PM

A manual trackback...

http://www.kirit.com/_fslib/_content/page.asp?id=1697036

(Not the correct permalink as your anti-spam filter wouldn't allow it)

Kirit on May 11, 2006 11:43 PM