Surround Your World

We’re investigating adding an annotate/blame feature in Surround SCM. If your not familiar with this concept, it allows you to mark every line in a file with the date, version and person who last changed it. For example, if the current version of your file looks something like this

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.

A few months ago we started our Quality Ready Assessment (QRA). This is a straightforward web tool to help companies and individuals measure their overall software quality level by asking them a short series of questions around overall application lifecycle. Companies who take this get a customize assessment, and internally we look at anonymize trends in the data.

We’ve gotten a tremendous response so far, and we continue to slice and dice the data to better understand how people who work in and around application development get things done. As a starting point, I’ve looked at the data for SCM usage and found some interesting trends.

The first one that jumped out at me was that 59% of the organizations have an SCM tool that does not support notifications and triggers. This means people are wasting time, plain and simple. This is a classic pull versus push model, where the “puller” is a human needing to know when changes have occurs. Anyone who’s been in the car of a family vacation knows how unsatisfying that kind of “Are we there yet?” conversation is from both sides. Far simpler is to get a call when something has changed.  A simple example of how I personally use this is to have Surround send me an email whenever one of the design or requirement documents change. Since the email includes the name of the file, the comments the person made when checking in the file and even a direct link to the file in Surround I always know when changes happen to the documents I care about.

Another fascinating one is that 55% of organizations have no integration between CM and their issue management solution. Being able to check in code and link that code to the issue that it addresses makes everyone more productive. Developers can mark issues as fixed as part of their normal workflow. QA engineers can see what parts of the application has changed to make their work more targeted. The whole organization is able to learn over time, rather than relying on memory (“What did you do to fix that bug last year?”,”Something with file handling. I think it’s in Foo.vb. Or maybe Bar.vb. Or something like that”.)

Something that won’t surprise anyone is that a recent SD Times survey found the top two SCM tools were SourceSafe and CVS, both of which lack this kind of functionality. While cheap is nice, the time it takes everyone on your team to manually work around these short-comings dwarfs the cost of any tool.
Grant has some related data that show, again to no ones surprise, that companies that use tools with these kinds of shortcomings suffer in the quality and schedule department as well.

The title of this post is the same as an episode of the TV show West Wing, and refers to Franklin Roosevelt’s bold plans for America’s effort around the WW II. Every good company should make big plans for their product. But asking people to achieve them using SCM tools without capabilities like notification and two way integration with issue tracking is like making 100,000 planes using hand tools. You could do it, but it sure isn’t very efficient.

My name is Jeff Amfahr, and I am the product manager for Surround SCM here at Seapine. After a groundswell of demand (thanks Dad!), I’ve decided to start writing about some of the issues exciting ideas and opportunities around SCM in general and Surround SCM in particular. In addition, I believe it’s only a matter of time before I’m slandered by Grant so I wanted to acquire my own mouthpiece. As Rupert Murdoch already snatched up the Wall Street Journal, this seemed like my best bet.

Over time, I’ll be keeping you apprised of what’s happing with the Surround product, soliciting feedback on directions and features we’re looking at and talking about some of the challenges exciting opportunities of working in this space.

Surround is a very interesting product, since we use it internally. This is a real mixed blessing. On the one hand, when things aren’t working well we feel it ourselves. I get feature requests all the time from team members. Developers “get” almost all of the use cases.

On the other hand, it’s easy to be blinded by our internal development process and use cases. “No one does it that way” and “It’s really important that XYZ be fast as people do that all the time” are easy to slip into the thought process.

I have to try and balance making features that I and other team members want/use to be perfect versus optimizing features that we don’t use, but some large part of our customer base might. And the challenge is how to find out what people are using (and why), since the feedback loop is rarely perfect. Hence, this blog as another avenue to let people in on the fun.

Hopefully you find the information here useful, as I give some additional insight into how Surround is evolving and you give me insight on how it should evolve. If nothing else, if you regularly read this as well as Grant’s postings, you run the risk might have the chance to be deposed at the inevitable lawsuit and/or criminal case.