Surround Your World

One thing I think about is release frequency. How often should we release new, non-maintenance releases of our software? As often as possible? Bi-annually? Yearly?

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.

Conversion can be a tricky business. No one wants to convert from one thing to another. It assumes you were wrong in some way. And you know it’s going to be hard. And what if the new thing isn’t really any better than the old thing? Then all that work was for nothing.

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.

One of the challenges with any product is how to handle “bad” feature requests. Not every user idea is a diamond in the rough. Sometimes it’s as simple as being very specific to that company/department/users use of the product. Sometimes what they want is counter to what the product is really designed to do. It may just be really, really hard. Or it just may be, in your opinion, a wrong-headed idea.

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.