Find-A-Bug Campaign
Tags: Teamstudio Products
For my inaugural post on Voices, I’d like to explain the background to the Find-A-Bug campaign we are now launching at Teamstudio. Like many companies these days, we use tools like Google alerts and TweetBeep to keep an ear out for anything people are saying about us. Most of what we come across is good and we always love to hear that. Sometimes we find someone who is having a problem that we can help with and we pass the details on to our tech support team. But last year I heard something that scared me. Paraphrasing, the tweet was along the lines of “Time to head home for the day - Analyzer has crashed again”. What hit me about that is not the fact that Analyzer crashed, nor even that Analyzer crashed ‘again’. The really scary part was the acceptance that, yeah, crashing is just what Analyzer does. It doesn’t even merit a call to tech support.
So, if you have a few minutes, I’ll explain why Analyzer crashes and what we’re doing about it. The code at the heart of Analyzer dates back around 12 years, to 1997. We were relatively new to Notes and, at version 4.0, Notes was a much simpler animal than it is today. The format that Notes uses to store its data internally is complex and relies on careful processing to read it correctly. The big mistake I made was to assume that the format described in the documentation was the only thing that we would ever find in a Notes application and
designed the code accordingly.
Looking back, that decision seems laughably naive. Over the years, we’ve seen databases where a data structure simply terminates half way through with the second half being complete garbage. We’ve seen databases where the middle part of a structure has been moved by two bytes for no apparent reason. We’ve seen data in totally incorrect formats. It is these unexpected situations that cause Analyzer to crash. We still don’t know quite what causes these situations. Sometimes we can track an issue back to the Mac Designer Client (remember that?). Sometimes we suspect a Notes beta or even a beta of one of our products might have written the data incorrectly.
Over the years we’ve fixed all of the Analyzer crashes that we have identified, but the nature of these fixes is that they’re always very specific to a particular data structure. Analyzer crashes are now rare, but there are many hundreds of data properties within Notes and the code for handling each one needs to be checked to make sure that it can handle anything it encounters without crashing. We have kicked off a project internally to completely protect all of our data-handling code. Our goal is to get to the point where no unexpected data can crash our products. Ever.
So we are launching a campaign we’re calling the ‘Find-A-Bug Challenge’. Why the campaign? I have two hopes. First, that we’ll find the bugs that are hurting you the most. It’s a huge task to bullet-proof all of our data handling code and although we’ll get to it all, I’d like to prioritize the areas that are causing the most pain. Second, I want to bring home to everyone within Teamstudio that it’s a big deal when our products crash. To our customers, I know that you’re insanely busy and that reporting our bugs to us is not high on you priority list, but if you can find time to let us know I can promise you that we’ll take the issue seriously. Bug reports don’t have to be fancy - if you have a database design that’s crashing one of our products and can send us a copy of the design, that’s all we need. No need for screenshots or lengthy explanations. So, what’s in it for you? Well, outside of just knowing that we are taking your issue seriously and will do out best to fix it, we’re also going to send out what I think are some pretty neat t-shirts to users who submit bugs to us.
If you think you have a bug to report, we would love to hear about it! We’ve put up some information about the Find-A-Bug Challenge on our website with details on how you can submit. And of course, if you have any questions or concerns, please comment below or feel free to contact me directly at mark_dixon@teamstudio.com.
For my inaugural post on Voices, I’d like to explain the background to the Find-A-Bug campaign we are now launching at Teamstudio. Like many companies these days, we use tools like Google alerts and TweetBeep to keep an ear out for anything people are saying about us. Most of what we come across is good and we always love to hear that. Sometimes we find someone who is having a problem that we can help with and we pass the details on to our tech support team. But last year I heard something that scared me. Paraphrasing, the tweet was along the lines of “Time to head home for the day - Analyzer has crashed again”. What hit me about that is not the fact that Analyzer crashed, nor even that Analyzer crashed ‘again’. The really scary part was the acceptance that, yeah, crashing is just what Analyzer does. It doesn’t even merit a call to tech support.
So, if you have a few minutes, I’ll explain why Analyzer crashes and what we’re doing about it. The code at the heart of Analyzer dates back around 12 years, to 1997. We were relatively new to Notes and, at version 4.0, Notes was a much simpler animal than it is today. The format that Notes uses to store its data internally is complex and relies on careful processing to read it correctly. The big mistake I made was to assume that the format described in the documentation was the only thing that we would ever find in a Notes application and
designed the code accordingly.
Looking back, that decision seems laughably naive. Over the years, we’ve seen databases where a data structure simply terminates half way through with the second half being complete garbage. We’ve seen databases where the middle part of a structure has been moved by two bytes for no apparent reason. We’ve seen data in totally incorrect formats. It is these unexpected situations that cause Analyzer to crash. We still don’t know quite what causes these situations. Sometimes we can track an issue back to the Mac Designer Client (remember that?). Sometimes we suspect a Notes beta or even a beta of one of our products might have written the data incorrectly.
Over the years we’ve fixed all of the Analyzer crashes that we have identified, but the nature of these fixes is that they’re always very specific to a particular data structure. Analyzer crashes are now rare, but there are many hundreds of data properties within Notes and the code for handling each one needs to be checked to make sure that it can handle anything it encounters without crashing. We have kicked off a project internally to completely protect all of our data-handling code. Our goal is to get to the point where no unexpected data can crash our products. Ever.
So we are launching a campaign we’re calling the ‘Find-A-Bug Challenge’. Why the campaign? I have two hopes. First, that we’ll find the bugs that are hurting you the most. It’s a huge task to bullet-proof all of our data handling code and although we’ll get to it all, I’d like to prioritize the areas that are causing the most pain. Second, I want to bring home to everyone within Teamstudio that it’s a big deal when our products crash. To our customers, I know that you’re insanely busy and that reporting our bugs to us is not high on you priority list, but if you can find time to let us know I can promise you that we’ll take the issue seriously. Bug reports don’t have to be fancy - if you have a database design that’s crashing one of our products and can send us a copy of the design, that’s all we need. No need for screenshots or lengthy explanations. So, what’s in it for you? Well, outside of just knowing that we are taking your issue seriously and will do out best to fix it, we’re also going to send out what I think are some pretty neat t-shirts to users who submit bugs to us.
If you think you have a bug to report, we would love to hear about it! We’ve put up some information about the Find-A-Bug Challenge on our website with details on how you can submit. And of course, if you have any questions or concerns, please comment below or feel free to contact me directly at mark_dixon@teamstudio.com.
| Permalink | 
