Selling to the Bottom & Coffee II

The golden rules of coffee, cream, and sugar:

1. The worse the coffee the more cream it needs.
2. In the limiting case, great coffee needs no cream.
3. No coffee is improved by sugar.
4. Not even sugar in the raw.
5. (In the raw? WTF?)
6. Cream is supposed to be made from liquid that comes from cows. Why do I even have to say this? "Non-dairy creamer" is not cream. I don't write code with a "Non-Java compiler."
7. Oh really? Read the ingredients and tell me that's "cream." Go on, click on the picture and read it.
   

Today we're pitching our software to the CTO of a public company. This is not the usual route for us.

We usually sell our code review software to software developers who have to review code. (Is that a palindrome?) Put another way, we sell a pain reliever. How?

It's easy to see why managers like peer code review. It will result in finding and fixing bugs, especially those related to documentation and maintainability and mentoring that no automated tool or unit test can find. They get nice reports they can show to each other "proving" productivity advantages.

But it's the software developers who bear the burden of this process. They have to gather files and file-differences for review, packaging them and sending them to someone else. They have to paw through comments that start with "On lines 834-837 of //depot/trunk/project/foo/bar.c." (Of course those lines have shifted around by now.) They have to track review comments over a pile of email from two continents. They have to track the problems found and get after other developers to fix it. They have to sit there with stop-watches and line-counters to generate those precious metrics.

This is dull. It's a waste of time. Proof-reading code is common sense, but all this process baggage sucks.

That's where our tool comes in. Sparing you the features chart, let's just say we remove this baggage.

Code Collaborator removes pain.

This is really the only reason anyone buys our tool. If it only generated metrics and reports, the managers would like it but developers would (rightly!) revolt and circumvent the system. And then even the reports wouldn't mean anything.

This is a "bottom-up" sales strategy: Genuinely solve a genuine problem for the guys in the trenches, then they beg their bosses to buy the tool to alleviate pain. Sounds reasonable, and even sounds like a positive contribution to the world.

But this next sale is "top-down." Start with the CTO and show why he should push this down everyone else's throats.

Of course we hope it's not that negative. But you always have to be skeptical when the boss-man comes by and says "Hey we just bought a new tool! Time to do code reviews! I've got some reports so get cracking!"

Some software tools companies work solely this way. There are ROI charts showing how you'll save $142,245 in the first 9 months of operation. There is the promise of "reports and metrics" (never mind interpretation). Sure the software is $75k just to get started but think of the long-term rewards.

Not us. I don't mind selling to the top, but to me this isn't about some imagined ROI. If you don't believe that proof-reading code will uncover defects, an ROI formula isn't going to convince you otherwise! If you do believe review will uncover defects, the cost of our little tool is clearly trivial compared to the cost of an undiscovered defect -- especially if delivered to a customer.

So I sell to the top exactly as I sell to the developer: "This will save your developers time and increase happiness." The sales books say otherwise, but I think you have to stick to the truth and stick by your mates in the trenches. If we're not truly making software better and people's lives better, screw it!

The brass aren't as insensitive as sales books have you believe.

Idiot! Buying SmartBear.com

Being slow cost me $2000. IDIOT!

Yesterday I bought smartbear.com.

Smart Bear started as a sole proprietorship. I switched it to a single-member LLC in Feb 2003, mostly just to see what it was like. (Single-member LLC's and sole proprietorships have identical tax consequences -- none.)

At the time Code Historian and Code Reviewer were shareware and the company name didn't seem to matter. After all, I had http://codehistorian.com, and that's better! So I didn't register smartbear.com.

Let me repeat that. I didn't register smartbear.com.

I could tell you I didn't have any money to spend on such things, which was true, but that's not an excuse, it's cheap. I could tell you I didn't think things would go so well, which was true, but that's not an excuse, it would have been cheap insurance. I could tell you I didn't think anyone was paying attention to little ol' me, which was true, but that's not an excuse, the domain trollers watch the chamber of commerce records and grab anything they can find.

There's no excuse.

By the time I came to my senses, a squatter had taken the domain. For a while the page was just broken. Then the page simply said the domain was for sale. $2000. I ended up getting smartbearsoftware.com.

The way you pronounce "smartbearsoftware.com" over the phone is:

"Smart Bear Software. One word. That's "bear" as in the animal. No, Smart Bear Software. You have to have the software. (pause) Yeah, I know, that's taken by a squatter. (pause) 2000 dollars. (pause) Yeah, we really should. It's the principle of the thing though."

And it really was. I offered the guy $1000. Rejected. I sent a lawyer-letter. Ignored. I asked the lawyer how much it would cost to actually pursue this. Minimum $2500. (Ah, that's how the price was set!)

I pointed out the trademark. He responded by saying it wasn't a registered trademark. I started the process of registering all our trademarks, but years later we're in the last stage of the process but still waiting.

I was goaded into this by the other bears. "Just get the domain. We know it sucks. We know it's unfair. But stop making us type 'software' all the time like chumps."

The final straw was a conversation with Chris Boyd, co-founder of the Best Little ISP on the Planet, Midas Networks. I told him about the domain. "Yeah," he said, "you just have to pay those guys." Chris always tells it straight. That's when I know I was sunk.

So I did it.

DiY Projects & Coffee

Ahh, the in-room coffee pot. Yes I'm going downstairs soon to toast an English muffin, but first coffee...

You know the one about why man-hole covers are round? The makers of this coffee pot didn't get the memo.

Water temperature in the shower ranges from arctic to frigid. Where's that coffee?

The second (potential) customer we're visiting today is having an in-house mutiny. Some want to use our software to do their code reviews, others want to write their own.

There are, of course, reasons to build versus buy, but typically in our space the "build" argument is pretty thin. Any time you have integration (code review system with version control, code review system with issue tracking, code review system with diff tool) you have a never-ending string of little problems.

Take integration with Perforce. When Perforce is about to come out with a new release of their software they send it over to us with a version history so we can check it out. We're able to run our complete unit-test and integration suite on multiple platforms for both client and server, including combinations of earlier versions of both our software and Perforce's.

So by the time the customer installs the new version of Perforce (and possibly the new version of Code Collaborator, in case some changes were necessary), everything works.

If you build it yourself, who is going to baby-sit this and the litany of feature requests? Who's going to field tech support for Safari? Typically one or two people get this role. Call it 1.5 annual developer salaries. Out here (Milpitas), ballpark estimate for this is $250k per year once you include all expenses.

That's $250k per year. Instead of 1/10th that if purchased from us. And the in-house tool will never have as many features (even creature-features, not just "stuff we don't need anyway") as we will with our small but determined army of top-notch developers.

The usual counter-argument is "We'll get exactly what we want." More accurately, you get exactly what you build. You know that what users want and what features are required to let them work effectively are two different things. You know that it takes time and iteration to get there. This will be a full-time software project like anything else, otherwise it's not going to be good.

So we'll see how this demo goes. It's always interesting to hear exactly what someone wants. Often it shows the way to great new features. Then everyone's happy.

Out of coffee...

Black Shirts

Always get black shirts for road trips.

The Smart Bear shirts are all black. Why?

• Coffee doesn't show up on black shirts.
• Spaghetti doesn't show up on black shirts.
• Everyone looks good in black.
• Black doesn't show wrinkles as much.
• Black makes you look thinner. (Thanks Penny!)
  

It is true that white dirt sticks to black while black dirt sticks to white, but white food doesn't stain.

We're bringing a bunch of shirts with us on our latest road trip. Giving away shirts is cliche but people still like them, especially developers who aren't allowed to visit tradeshows anymore. Also we give away real shirts with collars. They're actually nice.

Road Trip! Product Planning by Customers

We're going on another road trip. This time we're touring Silicon Valley. How original!

18 meetings in 8 business days. This is going to be fun...
Half of the meetings are with existing customers. We'll be showing off all the cool new Collab v2.0 features and demo'ing a brand new product that we just filed a patent for. But more on that in another post.

It's vital to keep in close contact with your customers. Your sales force will ignore customers as soon as the money is handed over (until a year passes and they want maintenance revenue). This is fine for the sales guys -- after all their job is to find fresh meat -- but it's not OK for customer service or for product development.

It's your existing customers who know what needs to be built next. They know which parts of the software are most annoying. They think of cool new features that would genuinely help their lives, not just put up pretty bullets on data sheets.

Sure they send complaints and ideas to support@. But that's nothing compared to what happens when you meet face-to-face.

I'll be walking down a row of cubicles and our host will causally announce that "The Smart Bears are here." I'll see a name I recognize and pop in. "Oh hey! I've been meaning to tell you guys, it really sucks that the search results page won't show more than N entries. I have to do this thing every release where I .... and it would save me hours if only it would ....."

Why didn't that guy email us? Doesn't matter, the point is he didn't. But when you're there everything's different.

Sure you can't implement every suggestion. And some will confuse more than help. But this is the only way I know to build software that people actually want to use. You can't compile it from stray emails.

Some people swear by Customer Planning Sessions. You can take managerial representatives from 10 companies and fly them in for two days of exciting meetings about what they want to see and what you're planning to deliver next. Seems fine, but my experience is that the folks that show up are rarely the folks that actually use the software. You certainly get great information about what the managers need -- and that's 1/2 of what we focus on with Code Collaborator -- but the other 1/2 are the developers who stare at the screen every day and you have to make them happy too.

It is possible to give managers reports, metrics, dashboards, and all that other process/control/measurement stuff and yet also have a pleasant, helpful, useful environment for ends users too. You just have to listen!

I thought XML-RPC was supposed to be easy

I love XML-RPC. The devil is in the libraries...

XML-RPC is the poor man's Web Services: A simple protocol for sending structured, function-like RPC messages and receiving a structured response. And really simple -- not simple as in Simple Network Management Protocol -- simple as in the spec fits on a couple of sheets of paper. It works on all platforms and languages.

We use XML-RPC for all our client/server communication. We use Apache's Java XML-RPC library on both ends.

The problems started with OS/390. (Surprise.) A customer was trying to run our client on a Linux partition and of course the default character set was EBCDIC. We don't officially support the Mainframe or EBCDIC, but since Java is write-once-debug-everywhere and since IBM is fully committed to both Linux and OS/390, we shouldn't have any problems, right?

Anyway, the problem wasn't with our code -- the communications were properly encoded. The problem was that Apache's XML-RPC library used the system default character set when creating the HTTP header instead of hard-coding ASCII as required by the MIME spec since... well since OS/390 was invented.

Turns out it was a "known issue." OK, it's open-source, we'll just modify it. We did.

That was library v2. Then v3 finally exited alpha with features we wanted, especially "streaming mode." (Yes, in v2 you had to build the entire request/response in memory before it would be transmitted. Yes this gave us problems transporting really large files for review.)

Also v3 supposedly fixed the OS/390 encoding problem! We can go back to a clean library instead of our hacked version.

Not so fast. In v2 we were allowed define functions that return nothing (void). The XML-RPC protocol requires that every function return a value. v2 glossed over this and all was well.
When we upgraded to v3 everything broke. Now it's not legal, and enforced. No problem, we'll just change the interface! Wrong, then old clients break. And new clients can't talk to old servers because the client-side v3 XML-RPC library complains about not having a return value.

The best we could do is make a new XML-RPC namespace (now we're up to "ccollab3") where "void" functions now return a dummy value. New clients use the new namespace; the old namespace is also still available. Old clients work on new servers, but new clients cannot talk to old servers.

And now all changes to the XML-RPC interface get a pass using the XML-RPC spec, just in case.