I apologize, I just keep quoting from
Eric‘s blog, Lessons Learned. But he’s on fire, and a lot of what he says just resonates with me on a basic intuitive level. It’s a little like watching The Mythical Man-Month unfold in front of you in close-to-real-time. I’d put down a bet right now that Eric’s collected writings will become a book some time in the next decade.
Fear early, fear often – by actually doing continuous deployment before we were really “ready” for it, we got used to the real benefits and consequences of acting at that pace. On the negative side, we got a visceral feel for the kinds of changes that could really harm customers, like commits that take the whole site down. But on the plus side, we got to see just how powerful it is to be able to ship changes to the product at any hour of the day, to get rapid feedback on new ideas, and to not have to wait for the next “release train” to put your ideas in action. On the whole, it made it easier for us to decide to invest in preventive maintenance (ie the Cluster Immune System) rather than just slow down and accept a larger batch size.
…
When a new engineer started at IMVU, I had a simple rule: they had to ship code to production on their first day. It wasn’t an absolute rule; if it had to be the second day, that was OK. But if it slipped to the third day, I started to worry. Generally, we’d let them pick their own bug to fix, or, if necessary, assign them something small. As we got better at this, we realized the smaller the better. Either way, it had to be a real bug and it had to be fixed live, in production. For some, this was an absolutely terrifying experience. “What if I take the site down?!” was a common refrain. I tried to make sure we always gave the same answer: “if you manage to take the site down, that’s our fault for making it too easy. Either way, we’ll learn something interesting.”
Yoav Shapira's Personal Blog 