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 steal borrow learn from others. Now back to that plan for re-educating users to all think alike.

ShareThis

Now, it’s easier on Linux and Solaris since the only GUI standard is to have one. Everything after that is gravy. And as a long time Windows user and developer I can say that not even Microsoft can always agree on how to do things. But Mac users often have a different expectation. Hitting command W always closes a window. Always. That isn’t to say that all Mac programs religiously follow UI guidelines, and Apple is often offender number 1, but I think that in general things are more uniform and conventions are more commonly adhered to.

So what about Surround? Did I mention we have a fully native client? Although we’re pretty good in a number of areas, we can do better. Some of our command keys don’t map to the generally agreed to convention. We don’t always follow the latest user interface guidelines (for example, there are a number of places we should be using sheets rather than dialogs on the Mac). I’d probably give us a grade of B minus, but I’m looking to make that an A as soon as possible.

That’s were you come in. Since I bounce around between platforms, I sometimes miss places where we aren’t native enough. If something in Surround seems less than Windows/Mac/Linux/Solaris native, drop us a comment either here or at the feature request forum. Since we go through all the effort to create native clients (and servers) on all those platforms, there’s no reason they shouldn’t go completely native.

ShareThis

Despite that, Seapine Software in general and Surround SCM sales in particular are doing well. We’ve had good growth each month this year, and good growth from last year. I’d like to believe that this is due exclusively to outstanding product management. A steady and seasoned hand at the wheel, guiding Surround through the rocky shoals of a troubled economic sea. I’d like to believe that, but I’ve been told in no uncertain terms by everyone around me that it just isn’t so. There even seems to be small but vocal minority that believes we’re succeeding despite product management, not because of it. Apostates.

More likely is that it has something to do with the concepts discussed in this white paper “Quality-Centric Application Lifecycle Management in a Down Economy.” I think many companies have gotten savvy to the fact that when the economy is tight, people want to make sure the things they spend money are worth the cost. And that means people raise their quality expectations.

I have a friend who is a CFO, and one of his sayings (besides “Cash is King”) is “Revenue covers a multitude of sins”. When revenues are down, companies demand the highest quality. I think people understand this, and want to make sure that the products they produce have as few problems with them as possible, to ensure that every sales goes well and every customer is a happy one.

That’s where Seapine comes in. Our products are all about making you more productive, producing higher quality products so you can survive and grow during tough periods. I’d really encourage you to take a look at the white paper I referenced above. This is especially true if your company is looking at some belt tightening and every project and activity is under scrutiny. This is a time when you need to increase quality, because you can’t afford a frustrated customer. You can’t afford inefficient processes that lack repeatability and reliability.

I can’t directly change the state of the world wide economy, but I can try and make sure that our customers have the kind of sales growth that we are experiencing. Because the only thing worse that being in a slow motion crash, is knowing that you could have avoided it.

ShareThis

For the Macintosh users in the audience (we’re the ones looking all smug and superior till we have to connect to our companies Exchange server), I’d like to draw your attention to some AppleScripts written by yours truly. The first is here and provides some instructions on how to use Microsoft Word on the Mac for merging and diffing documents. In addition, this has some AppleScripts for adding common Surround commands to the Word menu on the Mac.

For everyone, there is also a python script to provide a rudimentary annotate function. And this is a whole set of sample trigger scripts. You may even find a set of Window batch commands for putting Surround reports on your web site.

Since this is the lab area, some things can be a little raw. And don’t be surprised if you blow the dust off a link and find something that now is incorporated in the product. But hopefully this is a collection of tricks and scripts which can make your use of Surround that much better. Feel free to wander around the lab, and take anything you like. Just don’t put anything you find there in your mouth. Those AppleScripts can leave a nasty aftertaste.

ShareThis

But security is something that lots of applications get wrong, for lots of different reasons. First, I should say that I’m not a security expert. I read Bruce Schneier’s blog and newsletter (so should you), along with all his books.

With that said, I know that real security is hard. And one of the things to understand about Surround SCM is that the security we focus on is the internal security of the application. That is, how do we prevent users once they have authenticated themselves (either using our internal authentication or an enterprise solution like LDAP or Active Directory, both of which we integrate with) from doing things they should not do.

My mental model for this is primarily that our administrators are using our security settings to either make their users lives easier or prevent them from doing things they didn’t mean to do. For example, restricting users access to some branches and repositories is often used as a way to limit the list of branches that people have to choose among. Restricting their ability to permanently remove files prevents them from doing something that really needs a whole lot of thought first and probably isn’t what you want to do.

That doesn’t mean that our security isn’t for preventing evil doers from, well, doing evil. It is. But I think most of our customers are less focused with bad users and more with mistaken users.

I’ve been looking at other products in our space, and I’m often surprised to see the approach they take to security. Either they do very little, or they require you to write custom code to accomplish what you want. One company asks you to write Perl scripts in order to enforce restrictions on commands . Now, in theory, that is very powerful. You could write your script to make sure that only users whose last name begins with Q can destroy files, and only on alternate Thursdays. That is, if you need that. And can write Perl. And can debug Perl (clearly a separate skill from writing Perl, based on my observation.) And you want to spend your time writing and debugging Perl scripts rather than, oh, I don’t know, working on the things that make your company money.

I recently saw a presentation from another company that said over 5 years only 10%-15% of the total cost of ownership of an SCM system is license fees. I’m willing to bet that if you skip looking at how security works in some other SCM system, at least some of that other 85% will be spent on liquor to help you through those Perl debugging sessions. But just look at how cool drag and drop is!

ShareThis

Repository differences

This was mentioned in our last newsletter but I think it’s worth pointing out again. The Repository Differences window shows the difference between the server repository and your local working directory. This includes files that are missing from your working directory as well as files in your working directory not in Surround. It can even do this recursively. Check out the newsletter or the user documentation.

View/Edit file options

If you don’t want to use the internal viewer or editor for files, you can easily customize what to do using your user preferences. If you have a favorite XML editor, for example, you can tell Surround to use that when double clicking on an XML file. This is especially useful for text files, which all default to the internal editor.

File list and Repository menu

Speaking of user preferences, you can customize the list of items in the context menu for files and repositories. That way, if there are some actions you rarely perform (like sharing files) you can remove the clutter from those menus. This is also a great chance to take a look at some items like the new Open Containing Folder feature we added in Surround 2008.1.

Changelists

Although one of the primary uses of changelists is to guarantee a set of actions occur atomically, they are also a great way to group a set of actions together and give them a name. Unlike a lot of other SCM systems, Surround allows you to give changelists a human-readable name. Then, if you ever need to know “what were all the things I did to address this request” you can pull up your list of committed changelists and see.

ShareThis

On the one hand, I like to give user continual improvements. When people come up with great suggestions, especially when they are straightforward, you want to get them out into peoples hands. Customers will sometimes say “How hard can it be to add XYZ” and often they are right (though just as often they aren’t.) Sales and marketing folks often like something new to talk about, but making them happy isn’t always high on my list.

On the other hand, frequent releases can be a hassle for large (and small) companies. You might need to validate that the software doesn’t break something else you use. You might need to push the update out to lots of desktops. And the constant “noise” of releases can be annoying to decide if this release is worth the time of installing.

This is, of course, separate from your development process and “internal” releases. You can still follow an agile style process, and just release externally on a slower calendar.

So what’s the answer for Surround? I tend to lean more toward major releases every 12-18 months, with a minor release somewhere in the middle. The minor release should include few or no substantive user interface changes to existing functionality. Maintenance releases (with bug fixes only) as needed, of course. Hopefully that’s often enough for users to see the product incorporate their ideas while not forcing them to constantly look at new releases to see what 3 new features are in it.

ShareThis

It seems like when contemplating a move to a new platform like Surround from an existing one, you go through the seven classic stages of grief.

• Disbelief: Can we really move over to a whole new SCM system?
• Denial: It’s just too big a process. Maybe next year.
• Bargaining: Maybe we’re not using are current system right. Let’s try harder.
• Guilt: We’ve got this huge investment. How can I just throw it all away.
• Anger: Why is our current system such a pile? How could a company ship this kind of crud?
• Depression: I’m going to be swamped just installing and understanding this new system for weeks.
• Acceptance: Fine. The sooner we switch over to the new system the sooner I can get back to real work.

I bring this up, because we’re talking about conversions internally. Today, we provide a number of conversion tools from other companies SCM tools to Surround. We do this because so many of our customers our moving from a competitive product to ours. However, I’m not sure it’s actually in anyone’s best interest to provide these tools.

When people use an inferior product, they find ways to cope. They come up with “creative” branching strategies (like not branching at all). They use labels in fun and exciting ways. They use weird naming conventions to convey metadata. That’s the reason they are moving off their current system. So, why is it a good idea to try and convert and reproduce all that in their shiny new Surround system, which doesn’t have any of those limitations?

In addition, no matter how good our conversions tools are they inherently involve some level of mapping. Labels, branches, security are all similar but slightly different in each tool so after conversion the system will be similar but not identical.

Finally, I think after the conversion is complete a number of customers realize they don’t want it. I know that before I joined Seapine, I converted to Surround from Visual SourceSafe. After the conversion completed, I realized that as part of moving to Surround, I wanted to rearrange my repository structure, so I threw that out, created my new structure and checked in the tip version of all my files. I also kept my SourceSafe server running in corner for the odd occasion I needed something from item.

Considering all that, and considering the amount of time to support, enhance and test conversion tools is this a good use of time? Would customers be better served if we simply stopped converting their data, and instead focused our resources on continuing to improve Surround? If you converted to Surround from another system, I’d be interested in your thoughts on how it went, and if you regreted converting rather than starting over.

ShareThis

In any of these cases, what do you do with that idea and how do you convey that back to the user? The typical approach is to respond with something along the lines of “Your input really matters. Thanks for the idea. We’ll definitely consider it.” And that makes everyone feel good, but it’s not entirely truthful to anyone.

In the book Nuts!, by Kevin and Jackie Freiberg, about the success of the Southwest airline, the authors tell the story of a frequent complainer. At some point one of the person’s letters found its way onto Herb Kelleher’s desk, who was CEO at the time. He wrote a letter in reply of: “Dear Mrs. Crabapple, We will miss you. Love, Herb.”

That works somewhat best when you are the president of the company, but none the less I think letting people know that their suggestion is not likely to be incorporated is a reasonable way to treat people. The real downside is it invites a debate.

User “You’re missing the point, this feature would rock.”

Developer “I’m not sure you appreciate the level of effort and small return on investment in supporting the TRS-80 with a Surround Client.”

User “Oh, I see. You’re just lazy.”

Another common response is, “Well then, just make it user configurable”. The issue with that is, it takes even more work. You have to code the feature, the interface to turn it on and off, test everything under both scenarios, and then document all of it.

In the end, I think it depends. Sometimes the right thing to do is say you’ll consider it. Sometimes you should say no, and explain why. The important thing is to have a clear vision for the product and make sure your’re tracking user requests (in TestTrack, of course) so that you can make sure the product is moving forward in a reasonable way. Feel free to comment, because you’re input really matters. Thanks for the idea. I’ll definitely consider it.

ShareThis

int bar;
bar=7;
bar++;
if (bar>7)
    printf(“Big bar”);

The after running annotate, it might look like

Version     User        Date
25          gatesw     1/12/2008   int bar;
23          gatesw     2/25/2007   bar=7;
25          gatesw     1/12/2008   bar++;
8           ballmers   1/11/2006   if (bar>7)
7           gatesw     5/15/2005        printf(“Big bar”);

In looking at this feature, I discovered there was some “unease” about it, specifically around the name. It centers around that blame word. No one likes to be blamed for something. No one wants to play the “blame game”. “Let’s not finger point, let’s solve problems!” Blech. I think I threw up in my month a little just writing that.

Early on it seems to be generally called blame, but later systems started using the name annotate. Much nicer. While the actual name might not be critical, how people use it is and I think the “blame” word makes more sense.

I’ve used functionality like this (or simulated it) for a while, and I have to say it was most often for  blaming someone. I saw some code, and I wanted to find out who was responsible for it. Often it was to have a reasonable discussion. “Can you help me understand what this code does.” “We’re not using that approach any more, can you change it.” Certainly there were occasions when it ran more along the lines of “Who’s responsible for this mess?” or “Who dared to touch the perfection that is my code?”. Though, as the title of this post reminds, just because someone changed something it doesn’t mean the problem you’ve run into is because of that change.

You can certainly use this kind of feature for code reviews and related activities to understand the history of file. But I believe that the primary use case is when you see some changes that you question and want to track down the responsible party.

I don’t think there is any issue with that, and thinking of this feature in that way may drive different functionality than assuming it’s most often used for code reviews and such. For example, if the primary use is for code reviews, then you might want to really make sure you have excellent printing and exporting capabilities. On the other hand, if blame is your game, then you want to make sure it’s very interactive. You might want to easily see what other changes went in with that version. What other files were changed by that user at the same time.

I guess we could call it “responsibility”, but that doesn’t exactly role off the tongue either. The fundamental question still remains, though. What is the primary use for functionality which allows you to identify the person who last modified a set of lines in a file?

I’d be interested in peoples feedback on how they might use this. And if you don’t like how we implement it, please don’t blame me.

ShareThis