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?