Debugging 201

Almost all software has bugs. This includes SpamButcher.

As SpamButcher has become more successful, we've gotten more bug reports. This initially caused some panic - we were concerned that new problems may have been introduced into the software as the result of recent upgrades. Further research suggests the problems aren't new, but more people are trying the product - so we get more problem reports.

What little data we have tracked over the last few years confirms the bugs do exist, but most users don't see them. They seem to manifest themselves in a serious fashion for about 5% of users. That's the great thing about trial software. If a user's setup is prone to reveal problems with SpamButcher - they can find out before purchasing. There are other Windows spam filter programs available - for some potential customers they may present a better solution.

But still, it would be beneficial for everyone to actually identify and solve the problems in the software. One barrier to this is that SpamButcher does employ third-party components for certain functionality. This initially sped development, but it also makes eliminating problems within the components difficult to near-impossible.

Newer versions of SpamButcher now include built-in crash-reporting. When SpamButcher restarts after a crash, the user has the option to send log data to SpamButcher. Adding this code has definitely taken time away from focusing on the product core purpose - block junk e-mail, but it's been needed to ensure a good user experience.

It also allows us to monitor the impact of changes to the software. We can determine with some confidence if new "bug fixes" actually solve issues, as opposed to just creating to ones.

Back