Ben and I are working on a big enhancement to our core Game Stream feature. It’s a huge improvement that requires upheaval of a ton of Javascript. We’ve got to do it fast, and we can’t break our existing Game Stream in the process — customers pay for it and they count on it!
To keep risk in check while moving quickly, we’re deploying continuously. Various aspects of our new feature are going live throughout the week, even though the feature itself is still hidden from customers. On Monday, we replaced our stream poller with one that’s built on Backbone.js. Today, we started populating the models that will drive the new feature.
Problem is, we knew with complete certainty that our code was going to break, and we didn’t know where or why. Finding those points of breakage could take a ton of effort! Baseball games have tons of states and weird data conditions, and our quickly assembled code couldn’t have accounted for all of them. It would take a day of testing to figure out all of the cases we didn’t account for, and we’d still miss something huge.
So we’re getting our customers’ browsers to help us out without disrupting our users’ experience. We surrounded our new code (the fruits of which are still hidden from customers) with a try/catch, and reported errors back to our servers. So, our customers are finding our bugs for us, but, because we’re catching the errors, they aren’t feeling any pain from those bugs.
try
@set 'fielding', new FieldingPlayers(@makeFieldingPlayers())
@set 'offensive', new OffensivePlayers(@makeOffensivePlayers())
@on 'change', =>
try
@get('fielding').reset @makeFieldingPlayers()
@get('offensive').reset @makeOffensivePlayers()
catch innerError
logging.error "GameStream update error #{printStackTrace({e: innerError})}"
catch error
logging.error "GameStream initialization error #{printStackTrace({e: error})}"After a few minutes in production, we discovered a big bug and fixed it. We didn’t realize how commonly our Game Streams had no batter! Over the next few days, our code will keep running stealthily on customers’ browsers and it’ll report to us the errors that it finds.
Our crowdsourced bug-finding won’t substitute for real traditional testing. Along with Eric, our testing ninja, we will do that too. But our approach does help us find and fix more stuff sooner, and that will help us ship more quickly.
Can’t wait until we unveil our feature!