To Release or Not
Rahul has written about the electricity of release day and I totally agree with his sentiment - releasing is fun. Stressful, but fun.
Ultimately though, Release day comes down to a decision: Do we release or not?
There are always more bugs in the product than you’d like, and there always are more bugs that you haven’t even found yet.
The decision involves balancing the expected impacts from known bigs, the risk of unanticipated issues and the benefits of the “getting it launched”. Web companies, particularly those that don’t handle people’s money, have the luxury? of being able to iterate quickly on already released products and mitigate the risk of unanticipated issues through rapid releases.
We released an important milestone tonight that involved a significant shift in a number of core mechanisms on our deals site. There are also a lot of bugs. Even worse, we discovered a new performance-related bug after release - one that we wouldn’t have found in test or dev. The bug doesn’t look serious enough to roll back the release, but it is serious enough that it is a priority.
I’m still not sure whether I made the right decision to release. The user experience doesn’t appear to be that bad, and the perf bug would have appeared even if we delayed the release. We’ll spend the next few days fixing serious rather than trivial bugs, however we would have been able to address it quicker had we waited.
Related Posts
2 Comments
RSS feed for comments on this post.
Sorry, the comment form is closed at this time.
[…] last night’s release, as Dave mentioned, there were a bunch of changes to Judy’s Book and I’ll be writing more about those next […]
Can you post more info on the problem that you couldn’t reproduce in your test environment using your stress tests? It would be useful for others to learn what can’t be caught by normal stress testing.