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.
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
