Home > habits, programming, software development, test-driven, tools > Tools of The Effective Developer: Fail Fast!

Tools of The Effective Developer: Fail Fast!

It’s a well known fact that we regularly introduce errors with the code we write. Chances are slim to get it right on the first try. If we do, the risk is great that changing requirements and murdering deadlines will mess things up later on.

It’s also well known that the cost of failure increases with time. The sooner you discover the flaw, the easier it is to fix. In other words, if we are going to fail, there are good reasons to do it fast.

When developers talk about failing fast they usually refer to the defensive coding technique that is based on assertions and exception handling. It’s true that assertions are the very foundation of failing fast, they should be your first line of defense against bugs. But it doesn’t stop there. Failing fast should pervade your whole process of making software. You should fail fast on all levels.

The most effective fail fast-technique is automated testing, the fastest way to get feedback. Be sure to write the tests first. And don’t just automate unit-testing; integration and acceptance testing are often easier to automate than you might think. The key is to isolate your code using mock objects.

The fail-fast property doesn’t apply to code and systems alone. It should be used on the project level too. By using agile practices like short iterations, small releases, and on-site customers you create an environment of continuous feedback. It will help you steer the project to success, or – by failing fast – avoid a disaster. Kate Gregory puts it this way in a nice post from 2005:

“Failure can be a good thing. If it saves you from following a doomed path for a year, you’re glad to have failed early rather than late.”

Failing takes courage, failing increases your knowledge, failing calls upon action. That’s why I like the habit of Failing Fast.

This was the fifth post in this series. Here are the other Tools of The Effective Developer posts:

  1. Tools of The Effective Developer: Personal Logs
  2. Tools of The Effective Developer: Personal Planning
  3. Tools of The Effective Developer: Programming By Intention
  4. Tools of The Effective Developer: Customer View
  1. AC
    October 4th, 2007 at 16:19 | #1

    Hi Hans-Eric,

    I’d be curious to know how you automate (user) acceptance testing. I can understand automated integration and system testing, but I consider acceptance testing as something usually done by testers or real users.

    And in my experience testing is usually much harder than one might think and I consider finding good testers as hard as (if not harder than) finding good developers. But maybe that’s just me.

    An important thing to keep in mind when talking about automated testing (beyond unit testing) is that testing should always be done by someone else than the person responsible for the implementation. It’s hard to see your own mistakes. Basic stuff yes, but often neglected.

    Regs,
    AC

    • October 5th, 2007 at 10:05 | #2

      Hi AC,

      first of all, you are absolutely right about acceptance testing being a manual process. What I meant to say was that you can automate the acceptance tests. I wrote another post to clarify this, see the pingback comment below.

      You are also right in that testing is harder than one might think, and that good testers are hard to find. To me, this is just another reason to automate as much as possible.

      I also agree that testing should be done by others than the developers, but – and this is important – this doesn’t mean that developers shouldn’t test at all. I’ve seen too much of the “let the testers do the testing” mentality, and it’s always been disastrous. As I said, rapid feedback is the key to success.

  2. Dyan
    October 5th, 2007 at 09:37 | #3

    Nice article. People still don’t get that by failing fast on the short term they will actually succeed on the long term.
    I guess it’s just human nature to attempt to hide crap under the carpet.
    Would be interesting to analyze in more detail the impact of the fail fast approach on object responsibilities and contracts.
    Your blog is really inspiring, thank you!

    • October 5th, 2007 at 10:10 | #4

      Thank you Dyan, your comment is also inspiring to me!

      You really nailed it with this one:
      “I guess it’s just human nature to attempt to hide crap under the carpet.”

  3. AC
    October 5th, 2007 at 23:24 | #5

    Thanks for the clarification Hans-Eric.

    I’d like to add that I didn’t mean that developers shouldn’t do any testing, just that they should avoid testing their own work and perhaps ask other developers to test it. After all some things would be very hard to test without programming background for example.

    In that sense I would also consider pair programming and code reviews to be an important part of failing fast. Unfortunately both of them are often neglected and considered to be waste of time. [sigh]

    Regs,
    AC

  1. October 4th, 2007 at 00:43 | #1
  2. October 5th, 2007 at 09:53 | #2
  3. November 23rd, 2007 at 15:06 | #3
  4. March 4th, 2008 at 13:54 | #4
  5. September 7th, 2009 at 12:12 | #5
  6. October 31st, 2009 at 13:23 | #6
  7. January 22nd, 2010 at 14:36 | #7