It’s 1912 and Captain Edward Smith is boarding the RMS Titanic. He sees the lifeboats on deck and shakes his head with a heavy sigh before turning to the crew. “In my experience, I’ve never needed lifeboats. They’re not best practices — if you need lifeboats, that means your ship is sinking!” The crew members are enlightened and eagerly throw all lifeboats overboard. The Titanic begins its voyage to New York.

Okay, so that’s a silly story that no one would believe is true, but for some reason it’s easy to find the same kind of advice in the software industry. I once met a devops engineer who insisted that human access to production servers was bad practices. He was proud to say he’d completely locked himself out of all the servers he ran. “If you need to ssh into a machine, that means your automation’s failed!” Well, alright. When it’s 3am and you’re getting paged because your site has fallen off the rails, will “that means your automation’s failed!” really sound so profound?

Some claim that having the ability to roll back bad pushes isn’t best practices because if you need to roll back, that means your deployment procedures have failed. Others claim that if you need deployment procedures, that means you’re not doing enough unit testing before release. Likewise, the same logic “proves” that type systems and static analysis are only for those too morally weak to implement “best practices”. In fact, if you listen to some people, testing itself, along with any QA, refactoring, etc, are only needed by cowboy developers who aren’t disciplined enough to do things properly. (I wish I were making this up.)

Of course, that’s all backwards, and there’s nothing actually wrong with having a backup plan.