Wandering Thoughts archives

2008-08-10

Anti-spam work is pure overhead

Here is something that is perhaps obvious, but still worth mentioning: all anti-spam work is in a sense pure overhead, in that it is time and resources spent fixing a situation to return it to the way it was before the spammers showed up. Anti-spam work does not actually improve email in a broad sense, it just makes it as not-bad as possible.

(It is possible that anti-spam work will lead to techniques that improve email overall, perhaps better ways of automatically sorting and organizing email, but if it happens it will be a serendipitous side effect.)

This is one reason that I am out of the anti-spam game; I have come to realize that any anti-spam work that I do is 'wasted', simply time on a treadmill in an endless race to stay in the same place. While the race is necessary and vital, running it has ceased to be very rewarding or motivating for me and I am just as happy to let other people grind away on my behalf.

I suspect that people who are immersed in the race do not feel this. Because they are actively doing things, they are getting lots of feedback and so feel that they are clearly making progress; they are blocking spammers, seeing their clever techniques or code in action, and so on. This is not a bad thing, since happy, motivated people do better work and someone has to maintain anti-spam systems.

(I certainly often felt gleeful when I was actively maintaining local anti-spam filters. It was only when I stopped doing so for a while that the idea of doing more anti-spam work stopped feeling like fun and started feeling like a pain.)

spam/AntiSpamWorkOverhead written at 23:07:09; Add Comment

How to tell when your bug reporting system is at its limits

There reaches a certain point in the life of many projects, especially open source projects, when your bug reporting system just doesn't work any more. By 'doesn't work' I don't mean that your systems fall over and the software stops working; I mean that the system stops doing any good and instead becomes the place where bug reports go to die. (Actual important bugs get reported and often tracked by different channels.)

So how can you tell if you've reached this point? Speaking from an outside perspective, I have a suggestion on the boundaries of when a bug reporting system is still useful:

  • when you are getting more bug reports than you can fix, your bug reporting system is pretty much done for. Although you can still extract some use from it, you should start thinking about what's next.

  • when you are getting more bug reports than you can even sort and triage, your bug reporting system is dead. Give up entirely.

If you are in the second situation, ideally you'll remove your bug reporting system entirely so that innocent people are not deluded into spending their time filing bug reports that no one is going to read. If you keep your bug reporting system running anyways merely to divert people's attention so that they don't bug the developers, well, I will just say that I would rather that you were honest about the whole situation.

To be fair, I think that a lot of projects that wind up in the second situation keep their bug reporting systems running out of inertia and the idea that they have to do something to enable bug reports, instead of any deliberate cynicism. The Sam Ruby entry that started me thinking about this issue suggests that projects should take a different view, and as you might have guessed, I agree with him.

tech/BugTrackingLimits written at 00:04:01; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.