July 18, 2008

Opposition Research

Community
One of the things I do is look at competitive products. I do this both to understand their strengths and weaknesses as well as our own. Looking at someone else's solution to a similar problem can often give you a fresh perspective. As I looked at several of these, a few trends showed up. The first is that security in other products seems to be left as an exercise for the customer. I’ve talked about that before. Another area where other products take a very different approach is around triggers and alerts. This is another part of an application that either isn’t shown in a demo, or if shown the trigger is already installed and working. The user sees that emails are being generated or actions are being triggered with an aside of “all this and more can be yours with just a little script writing.” Now, I like script writing as much as the next person (well, assuming it’s not Perl). But I mostly enjoy it when I’m doing it for my own use. When I need it to work for all those crazy other users, then it starts getting less fun. People have this tendency to enter bad data. Or not think exactly as I do. And as much as I try and get them to follow my every command, they refuse. Perhaps when my application for the evil league of evil comes through I’ll have more success. Until then, if other people depend on my scripts then I need to put in thorough error checking. And progress messages. Bummer. Surround has taken a different approach. We let you write scripts or applications if that’s what you want or need to do. And sometimes you do. But we try to carry as much of the load as we can. First, we let you specify as much of the criteria for your trigger as possible. That way we won’t even call you if it doesn’t make sense. And you can skip writing code that checks, for example, the user, or group, or file name pattern, or branch. Second, we let you specify exactly what action (e.g. checkin, add, promote) and when (before or after the event) the trigger runs. Finally, for some of the most common actions you don’t even have to write a script. That includes generating an email, changing the file state, or preventing the action entirely along with a message letting the user know why. In a future posting I'll be listing some of the features I like in other products. And maybe some ideas of how we might incorporate them into Surround. If there is a feature or approach in another product, whether it’s a competitor to Surround or not, let us know. I’m not afraid to stealborrow learn from others. Now back to that plan for re-educating users to all think alike.