Fail fast


Projects fail. That itself is not an problem. In many cases, figuring out if an idea is feasible in the long run would take as much time as giving it a go. So you give it a go, and if fails. Though luck.

The big problem however is that projects fail late in the game. That means piles of money were spent on something that - with a little bit of effort - could have been proven to be a failure early on. And that’s just plain wrong. Projects should fail as early as possible, if there is a risk it might fail.

Edsger Dijkstra once said that whenever he had an idea, he first put in a considerable amount of effort to prove it wrong [citation needed].


All projects. But it extends well beyond the boundaries of projects. It also applies to the inner workings of software. If there is a chance it fail, make it fail as early as possible.


  • Have a list of risks
  • Estimate the chance that the risk materializes into a problem
  • Estimate the cost incurred as a consequence of that problem
  • Prioritize work to deal with the risks
  • Make it visible. Having a calendar on the wall that clearly highlights the risks and the moment in time we expected to have dealt with it might help.

The Xebia Essentials Cards

This page is part of the Xebia Essentials, a pack of flash cards about Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store.