OSS: A world of 12-day weeks and nuclear launch codes

I really enjoy the musings of Jason Fried. He blogs over here at 37signals, has written books such as “Re-work” and runs a successful (bootstrapped) software company. I enjoy his musings because they take a much more pragmatic and balanced look at the worlds of software development and business than most.

Let’s look at his recent post about 12-day work-weeks when many others are espousing a 4-day work week (or 4 hour work week in the case of Tim Ferriss):

“Today’s Friday, which happens to be the best day to remind yourself to look out for 12-day weeks. 12-day weeks? Way back when, we used to release new software on Fridays all the time. That often meant working Saturdays and Sundays to fix an urgent problem with the new stuff, wrecking the weekend for whoever did the release. It was stupid yet predictable, because we kept setting deadlines at the end of the week, as most naturally do. But Friday is the worse day to release anything. First off, you probably rushed to finish before the weekend. So work done on Fridays tends to be a bit sloppy. Second, Mondays don’t come after Fridays. Saturdays and Sundays do. So if something goes wrong, someone’s working the weekend. Third, if you work the weekends, you don’t get a chance to recharge. Basically, when you’ve worked all week, and you’re forced to work the weekend, the following Monday is the eighth day of last week, not the first day of next week. This means that if you keep working through the following week, you’re working 12-day weeks.”

Now, let’s consider this in the context of the world of OSS. Our releases tend to occur overnight and over weekends because of their potential to wreak havoc on production networks. It’s not uncommon for one week to blend into another when implementing a major go-live, release or upgrade. Or in the case of overnight releases, an 8-hour workday quickly devolves into a 24 to 36 hour panic.

Reminds me of one release manager who would set up a release, type in the command-line to trigger the release, hover his finger above the enter key and then look away. He couldn’t bear to watch. It was like he was responsible for nuclear launch codes… and come to think of it, a few of his releases did go nuclear, like this hilarious story!

But back to the main storyline. Jason and the team have also come up with a better way than a Friday release cadence (and 12 day weeks):

“…instead of shipping big software updates on Fridays, we now wait until Monday or Tuesday the following week. Yes, this introduced other risks — but we had the time and space to handle them. This encouraged us to take quality assurance more seriously, so we can catch more issues ahead of time. Reducing release-day stress was a multipronged approach. First comes recognition then comes remediation.”

Our OSS tend to be mission critical services and need to operate 24×7, so there’s never really the perfect time to launch. I’d love to hear your thoughts on Jason’s release timings and whether you have approaches that work well for you. Leave us a comment below.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.