Chapter 104. Fail Fast
Among movements like Agile, Lean Startup, and Design Thinking these days, you hear the term fail fast. The principle of failing fast is vital to efficiency, but I’ve seen project managers and business partners be offended or even agitated by the term fail fast. I’ve seen it come out like, “Why the hell would I want to fail fast?! I don’t want to fail at all.” The implication, of course: failing is for losers—if you’re planning to fail, then I don’t want you on my team.
I think I can help explain why the principle of fail fast is so important, and maybe I can help you explain it, too.
Software developers know about fail fast already, whether they realize it or not. In 2006, I blogged about an example.1 It had been a really long day. I didn’t leave my office until after 9 p.m., and then I turned my laptop back on as soon as I got home to work another three hours. I had been fighting a bug all day. It was a program that ran about 90 seconds normally, but when I tried a code path that should have been much faster, I could let it run fifty times that long and it still wouldn’t finish.
At home, I ran it again and left it running while I watched TV, assuming the program would finish eventually, so I could see its log file (which I wasn’t flushing often enough, which was another problem). My MacBook Pro’s fan was running so loud that my son asked me if it was OK. The whole time, I was thinking, “I wish this thing would fail faster.” And there it is.
When you know ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access