Outside-In

What do these things have in common:

1. The People's Republic of China
2. Smucker's line of "100% Simply Fruit" spreads
   
3. Scrubs will be right back after these messages

They all follow Brandon's Rule: If it's on the outside, it's not on the inside.

China is not a Republic, that Smucker's line is 30% juice, and there's no more Scrubs after the final commercial break.

When something is true, you don't need to announce it. You don't need to convince people of it. You don't have to draw attention to it.

Here's some more:

• We put customers first.
• We treat customers as partners.
• We have unmatched customer support.

The quality of customer support is something you notice right away. Either they answer the phone quickly, or they don't. Either the person on the other end genuinely helps you, or they don't. Either your "account manager" continues to provide service after the sale, or she doesn't.

I can't count the number of times I've heard a C_O say "What distinguishes us from our competitors is better customer service." Theoretically, having good service is not only a competitive advantage, it's also the primary way to develop solid relationships, promote word-of-mouth advertising (the best kind), and can even make a sale even when the first impression was unfavorable.

But you can't convince people you have good support by telling them so. In fact, telling them so might turn them off.

Here's what I tell folks in demos: "While you're trialing our software, also trial our tech support. Give 'em a call and test it out. Make sure we're responsive and helpful."

When you hit someone over the head with honesty, it leaves a mark. People are so used to hearing things like "We have unbeatable customer service" and "Customer service is priority number one," the words are water off a duck's back. Even if true, they're meaningless.

So when I tell them to try it for themselves, I get amazing reactions. "Wow," someone recently told me, "I've never had a vendor actually encourage me to call them for support." My response was: "Well, I could tell you we have great customer service, but you wouldn't believe me." His response to that: "I don't have to call. I already know you guys are going to rock."

When was the last time you built that kind of relationship with a potential customer during the initial demo? Just by being honest.

So don't say it, do it. Encourage potential customers to notice, but let them come to their own conclusions.

Microsoft isn't scary anymore

There, I said it.

Today, if Microsoft announced a direct competitor to Code Collaborator, I don't think it would affect our sales at all. And if they actually shipped a competitor, I don't think we'd notice that either.

In the 90's, a pre-announcement by Microsoft of a non-existent product could destroy a product line. The demise of Turbo Basic was an example (although in retrospect it was probably dead anyway...).

But now it's clear that Microsoft can't release a major product. As a shipping date approaches, the list of features shrinks, the new ship date is later, and betas never seem to settle down into stability. To this day Visual Studio devotees are easily amazed by features in other IDE's that have been around for years.

Compound that with Microsoft's self-imposed cross-product dependencies (e.g. Team Foundation Server, SQL Server), and now a slip in one component slips the others.

With each passing year we get fewer requests for Visual Studio plug-ins and more for Eclipse. With each passing year we continue to get requests for support in the latest edition of NetBeans but Visual Studio 2005 is still on the cutting edge for most of our Visual Studio customers.

If VS 2005 is still the most relevant Microsoft development platform, and as a percentage of serious development shops its share is decreasing, than how worried would I have to be to see a competitive product in VS 2008? Or one announced for VS 2009? When will that ship? And will that also take 3-4 years for adoption?

If anything it would help. Any press Microsoft can muster for a competitive feature means some people might be interested or convinced of its usefulness. Then with any Google searching they'll find us doing it nicely, available today.

So, oddly, I hope Microsoft tries to compete with us!

P.S. This is not meant to imply "Microsoft's death is inevitable." Microsoft is a big company with many factors determining its health and trajectory and lifespan. But they sure seem to be losing their grip on software developers.

Jolt Finalist: Code Collaborator

Code Collaborator has just been announced as one of six Jolt Award finalists in the category of "Collaboration Tools."

The competition is varied -- everything from wiki's to project management to collaborative development (us!). Hopefully, since this is a programming award, collaborative software development will be more relevant than general wiki's, but we won't know until March 5.

Not in the cards

Jeff Atwood recently posted an amusing treatise about shuffling cards demonstrating how sometimes the simplest algorithm isn't the right one.

Remember those open-ended interview questions that make you think deeply about a problem? Sometimes you actually need to do that in your job; it's not just an interview trick!

Card shuffling made me think of a similar, more common, and more complex problem of the "Shuffle Playlist" or "Random Slideshow."

(In the 90's we used to joke that "Every application grows until it becomes its own operating system." During the bubble we used to joke that "Every application grows until it is capable of sending and receiving email." Today I think the joke should be: "Every physical device grows until it is capable of playing mp3's or displaying pictures at random.")

The goal of the shuffled playlist isn't the same as shuffling cards. With cards it's sufficient to have a "randomized deck," meaning that every possible ordering of cards has an equal likelihood of being output by the shuffle algorithm.

The reason playlists and slideshows are more complex is: The goal is to make a human feel like the order is random, not to have it actually be random.

What's the difference? Imagine you have 5 songs. The algorithm for choosing the next song is to select one of the songs with equal probability and play it. Obviously this is completely random mathematically. Chi-squared will be happy.

But a human won't like it. It won't be uncommon (20% of the time) for the same song to be played twice in a row. Sometimes (1%) it will be played three times in a row! But that's not really what you want when you put songs on shuffle.

With an image slideshow it's worse. You're expecting images to change every 5 seconds (say), and sometimes it seems to get "stuck" (because the same image comes up twice in a row). Crappy slideshow player! Get a new one.

The usual fix for this is to take the entire playlist and randomize the order of the songs, rather than randomizing each selection of song. This ensures we have the perception of random distribution of songs. In fact it's not random at all by any mathematical definition. It's an even distribution, but not random one.

But that's OK, it's perception that counts. But we're not done! What happens when we go through the playlist once? You'd probably propose we just repeat the algorithm -- reshuffle the playlist and keep going another round -- but it's now still possible to repeat a song. The last song from the first shuffle might be the same as the first song of the second shuffle. A repeat!

In fact, the perception is probably marred even if any songs match near the "crease" between two shuffles. For example, if the last song of the first shuffle matches the second song of the second shuffle, that's probably still too close to "sound random." "I just heard this song!" exclaims the disgruntled, indignant user. And rightly so you bastards!

So now what? With larger playlists, you could start with a full shuffle, then take the last N (or N%?) of the first shuffle and check the first N of the second, and if there are overlaps you could swap songs from that initial "unsafe" region into the "safe" region, at random, being careful of course to swap only with songs allowed in the unsafe region.

"Wait," you cry, after having digested Jeff's excellent reasoning for why selective swapping is clearly for dummies, "that's not random!" No, it's not, and no one cares, because it's doing the Right Thing.

OK, so this swapping idea isn't great -- you can't do my version in place (because you have to remember the unsafe songs) and it's complex. Here's a simple, in-place algorithm:

1. S == number of songs, N == number of "unsafe" songs, meaning the last N of the first shuffle must not match any of the first N of the second shuffle.
2. Starting with the first shuffle, shuffle songs 0 through S-N. (This ensures that, at least, the first N songs are evenly selected from the set of songs allowed to be there.)
3. Now shuffle songs N through S. (This ensures that the unsafe songs are evenly distributed in the safe area.)

The keen eye will notice that if N > S/2, this algorithm fails. Indeed, you cannot satisfy the constraints in that case no matter what the algorithm because there's not enough "safe" songs to fill the "unsafe" region. As a simple example, if N=9 and S=10, we have only one song that is safe and nine unsafe slots to fill!

It's even worse for small playlists. With two items, the best you can do is alternate. With three, I would argue the best technique is to just keep any back-to-back's from happening -- anything more strict and you end up with zero variation, which doesn't feel like a "shuffle."

And don't think I'm being pedantic in calling out the cases of 2 and 3! That electronic picture frame on Grandma's sideboard might very well be displaying just 2 pictures, especially when you're first setting it up for her. First impressions are important!

So what's the lesson? In most applications, human perception is more important than mathematical correctness. And sometimes it's worth digging into your interviewee skills to cover a problem as deeply as you can.

In this case, a user unsatisfied with "shuffle" might not buy, might return the item, or might call tech support. A little thought and common sense could save many thousands of dollars.

Oh yeah, that's why great developers are worth a lot of money....

Choose your words

The headline in the Austin American Statesman:

Bush says Iran Still a Threat

The headline in the New York Times:

Bush Insists Iran Remains a Threat Despite Arms Data

Set aside political debate. Just consider how each of these headlines predisposes the reader while purporting to summarize the same event.

Marketing is about persuasion, hopefully more so than news outlets (!). How can you predispose your readers? How can you load the debate before it begins?

Every word in your headline counts. Use it to frame the debate before you potential customer even sees the competition.

I Will Survive

We make a peer code review tool for $400/person. What would happen if, today, Google released a peer code review tool? For free. And it's technically good, because it's Google. And because Google has tremendous visibility, everyone who's at all interested in code review goes out and tries it out. And it's open-source, so a community will be built around it and will add cool new features and plug-ins.

For free. From Google.

That's it for Smart Bear, right? No way we can keep charging for Code Collaborator, right? At least not at these prices.

I don't think so. Subversion is awesome and free and has a community, but Perforce charges $850/seat and their customers love them. Bugzilla is awesome and free and has a community, but JIRA, OnTime, Fogbugz, and TeamTrack have thousands of customers and continue to grow.

So how do you compete? You have to realize that it's not about selling software, it's about solving pain. No one sits around saying "What we need around here is another software tool!" No, even software developers themselves hate the idea of installing and learning a new application.

Here’s a hint: Imagine you have 100 developers under you and are charged with reducing bugs released to QA by 50%. Sounds fairly impossible (although our customers have seen these kinds of numbers). But how the hell do you do that without pissing off the developers or wasting time?

Your biggest concern isn’t whether tool A or B has the best diff viewer. It’s probably not even whether your initial tool cost is $0 or $30k. That’s nothing compared to the time, effort, training, and risk you’re taking on by doing any kind of peer review process. Not to mention your own reputation, and possibly your job.

The main blockade to code review isn't the tool -- it's the social change, the process change, the idea that someone else will be criticizing your code, the fear that pointy-haired bosses will be able to measure your "productivity" in terms of lines-of-code-changed and defect-density.

At Smart Bear we are experts in constructing practical code review, part of which involves a tool. All you can expect from a tool is to remove some drudgery -- integration with other systems means fewer mouse-clicks, organizing conversations and displaying them visually with the code is useful, collecting time-spent-in-review automatically so managers get their metrics but developers don't have to mess with stop-watches.

But if you're not good at reviewing code, it's still all a waste of time. Maybe you're bad at reviewing certain types of code? Maybe you'd get the most bang for your buck by reviewing just the code modules (where a little bug is a big deal) and not in GUI code under active development. Maybe some of these metrics are not actually correlated with anything, so you'll be chasing ghosts and making incorrect decisions if you look at them.

These are things everyone also worries about, and just installing a tool isn't going to fix it. But we can.

We give you a 164-page book for free that helps you make the right choices. There are articles and white papers on-line, for free.

And most importantly, you can call and we’ll talk about anything you want, for as long as you want. For free. That’s something no on-line forum or answer-by-Google-search can match.

So in light of all this, as the manager, will you go with the free Google tool with no assistance, no help, or do you want the direct phone line to the guy who literally wrote the book on how to construct truly effective code review processes?