Procrastinate for Success!

I'm a habitual procrastinator. It's a funadamental component of my psyche. It's also an important factor in success at running a small business. Here's why.


In a small company you're overwhelmed with things to do. At Smart Bear we still have a dense whiteboard full of marketing ideas we don't have time for, dozens of index cards with cool features we don't have time to implement, and 7,000 open issues and minor feature requests in Fogbugz we don't even have time to look at.

And that's now, with five years of work and fifteen employees. It was hundred times worse at the beginning with just one person to do all the work.

This one person must have worked tirelessly. (He did.) This person must have been willing to do every kind of job. (He was.) This person must have been hyper-organized, allowing nothing to slip through the cracks, spending precious time on only the most high-valued tasks, not just working on whatever this person felt like at the time. (Ummmmmm... <looks sheepishly at toes>... not so much.)

"Don't put off 'till tomorrow what you can put off 'till the day after tomorrow." Thanks, Mark, for guiding the overwhelmed.

You really do have too much to do. Prioritization might be best in theory, but plain, gut-feel procrastination might be the right way to go. 

Many things blow over if you just ignore them. The big feature you got worked up about yesterday seems unimportant in the cold light of today. A feature a customer says is vital turns out to be something suggested by their intern, not something actually stopping a sale. An apparent fundamental bug turns out to be a misconfiguration. An important meeting turns out to be unimportant.

Besides, a lot of those tasks aren't as important as you think. Even something critical like accounting can be put off. Late fees, lost receipts, penalties from the IRS: financial burdens more than compensated by additional revenue gained by signing up one more customer.

Financial tasks in particular also have the property of being faster to do in a big sweep rather than as they trickle in. It's faster to enter 100 receipts into Quickbooks once a month than to enter three a day. Little tasks like that still have context-switch overhead, plus you get fast at typing and keyboard shortcuts when you're doing the same action hundreds of times in a row.

Finally, sometimes you've got to let yourself do fun stuff at the expense of priorities. Most of what you do in a little company isn't what you enjoy doing; it's easy to become frustrated and burned-out. So sometimes you need to allow yourself to recover with plain fun. Whatever the cost of putting off duties, burn-out is even more costly.

Yeah I know I'm rationalizing.  But you can't do everything, so don't.  And don't beat yourself up over it.

No hats!

"Oh, you have a small company? I guess you wear a lot of hats!"

Ug. I've always hated that phrase. Recently I figured out why.

To me it's always came off as a smug comment implying the speaker knows just what it's like and understands your pain. It's usually followed up with something like "I was employee #7 once and I was VP development and VP QA!"

Yeah. How can people live like that? Unfathomable.

Real entrepreneurs don't talk about hats, but why not? Why do I recoil at this attempt at empathy?

I think it's because in real (bootstrapped) start-ups there's no such thing as hats, titles, or departments. If you don't realize that development, marketing, sales, and even accounting are all inextricably linked, you'll probably fail. You can't make decisions about any one in isolation. You're learning how to sell, what to build, what to charge, who will buy, all at the same time. You're never even thinking in categories like "Marketing" and "Development."

So I think my disdain comes from the implication that "many hats" proves the speaker "knows just what it's like," when in fact the very idea shows you have no idea what it's like.

People like that will always be employee #7, never employee #1. (Or really employee #0, since everyone I know who has created a successful bootstrapped company paid themselves last, long after other people were hired on, long after profitability.)

Which is fine! But the experience gap is bigger than they think.

Agile marketing interview at GeekAustin.org

I just got interviewed about "agile marketing" over at GeekAustin.org. It was fun to show how we apply principles from agile software development to business and marketing efforts.

If you're involved software or marketing in Austin, you should meet Lynn Bender, the founder and organizer at GeekAustin. Maybe come to the Agile Happy Hour in two weeks! They're always a blast.

Identity Crisis

This (stolen) picture of logos demonstrates a property of corporate image done well: Even when the logo is obscured in an unusual way, I can still identify the company.

I even distinguished the "The" from "The New York Times" and the "The" from "The Wall Street Journal."

Is your corporate image so unique that this trick would work for you? Here's a hint, if your logo is just some meaningless shapes made by a Photoshop weenie, the answer is no.

If your logo were a performer on American Idol, would Simon Cowell say "It was OK, it was safe, but your problem is you're forgettable."

So change it! I know that sounds scary, but if your image is already forgettable, changing it isn't a big deal.

Don't worry about confusing existing customers. Customers love you, not your logo. They will be pleased to see something interesting. They'll be happy you're making a bold statement about who you are. You can announce it to them if you're afraid they'll get lost. When we upgraded our logo not one person was confused and many complemented us on the new look.

Don't worry about resetting your brand equity. Unless you're Google or IBM, the vast majority of your potential customers never heard of you, much less have an attachment to a logo. Even if they've seen it a few times, if you're forgettable, they will have forgotten. Better to reset now and start spending money on an image they can remember.

Finally, remember that "image" is more than logo. It's the attitude of your prose, it's a cool give-away, it's a killer idea presented clearly. Make a bold, unique statement if you want to be remembered.

Discount gambit

Which of these pricing strategies is more persuasive?

1. If you buy now, I'll get you a discount.
2. The price is going up, but if you buy now I will lock in your rate.

Both are types of discount. The typical software sales strategy is #1. It's often applied to get the customer to "close" before the end of the month or quarter or some other arbitrary time boundary.

At first blush it seems harder to persuade with #2. After all, #1 means the customer pays less than #2, because #2 isn't a real discount -- it's a discount against some future price, which is a lot harder sell than a discount today.

But for me, the evidence is overwhelmingly in favor of #2. Here's why, from the point of view of the customer.

You've already established your price. In strategy #1 there's a discount if I "act now." Hmm, so that means the old price wasn't really the price after all. The old price must have included a nice slice of pure profit that apparently you're willing to leave behind. So you were gouging me before. And the only reason I found out about it is that it happens to be the end of the quarter?

This is how #1 breeds mistrust -- the opposite of what you're trying to establish with me, your customer. In #2 you're looking out for my interests. You're cluing me in that there might be a rate increase, and you're actively protecting me from it. Sure, I know there may not be an increase, or it may not come for a while. But it's still protection, not a gouge that you graciously chose to reveal.

Four years ago I was trialing .TEST from Parasoft. It was buggy; even after hours of remote desktop control with tech support we couldn't get it to stay up long enough to scan my code.

But the salesman was persistent. The conversation went like this, minus many minutes of sales-speak on his end of the phone:

"How much will this cost me?"
"$20,000."
"Wow, I thought you were going to say $2,000. That's way out of my price range for one person and this product. In fact, I've looked at FxCop and NUnit and [something else] and it seems to me I can do the same thing with free tools. I was willing to pay for some convenience, but not that much."
"Let me see what I can do."
"No nevermind, it's, like, an order of magnitude problem."

He called back the next day.

"$1,500."

I didn't buy. I talked to someone who did, though. A reference customer. That guy said he paid $20,000. I asked how he liked it and whether he encountered the crash problems I was seeing. He said they hadn't installed it yet, but the demo looked great. I made a mental note to try to understand the mentality and budget that forks out $20,000 for a nice demo.

But getting back to the point. If he can go from $20,000 to $1,500, maybe he will go to $1,000. Yes, this strategy means often you will extract extra money from me. But it also means I don't know where the floor is, and I have every incentive to haggle. The process drags out, ending at gunpoint. Meanwhile your "customer relationship" is now more of a "hostage situation."

So let me get this straight: It's better to get an extra 10% on every order, but create an adversarial environment with me, your cherished customer? This is enterprise sales, right, where the pilot is 30 seats and the roll-out is 2,000? And you're going to risk pissing me off over 10% on the 30-seat part?

And now imagine if I had called back that reference customer and told him he could've had it for $1,500? Yet another problem with discounting -- word gets around, meaningless differences in pricing is unfair, and now I, the customer, see you as plain old dishonest. Goodbye 2,000 seat order.

Even if we set the honesty/relationship argument aside, there's the matter of image.

What kind of company provides a #1-style discount? Wal-Mart, Target, Walgreens. No, software companies. Try to get quotes for Microsoft or Oracle or IBM products for 1000 desktops. Everything's negotiable, everything's discountable. At best it conjures images of haggling and struggle; at worst of low-quality or the desperate need to "meet numbers" at the expense of everything else.

Which companies don't discount, ever? Apple, Google, Constant Contact. No discounts on iPhones. No haggling over AdWord prices. What's the image? Desirable. The best. Worth paying for. The leader doesn't have to compromise. The leader isn't desperate for orders.

Strategy #2 implies growth. You've planted "higher prices" in my head now. Supply in software is unlimited, so that must mean demand is increasing. I won't go through that calculus, but certainly I feel the product is becoming more valuable, not less. Discounts feel like unloading unwanted product; price increases feel like success.

Strategy #2 implies I'm part of a club. I've gotten in early, on the ground floor, before the product explodes in popularity and prices go up. And I'm rewarded for this support and loyalty with price protection. A "thank-you" from you to me because I was part of it, because I was there before you were big and expensive, because I took that risk with you.

So there it is. #1 means less money now, an adversarial relationship, a never-ending struggle over money, and a message that maybe the product needs a discount to be desirable. #2 means more money now, a consistent and fair pricing policy, an inclusive, special customer relationship, and a message of market leadership and growth.

So why do 90% of software companies pick #1?

Resumes considered harmful, or at least useless

In our recent hiring effort, I've noticed that I've approached all the resumes the same way: I don't read them.

Sure, I go through the resume before the phone screen, marking passages for discussion. Hope for the best, prepare for the worst...

...Oh you know 11 programming languages? Great, let me ask you a deep technical question about number 9, Visual Basic. How do you get the length of a string in Visual Basic? No idea? Oh you'd look it up. So the extent of your knowledge is your bookmark to the "Visual Basic Functions" page in MSDN on-line. OK, so which of these can you actually answer questions about? Just Java? OK...

...It says here you were the team leader in developing a reporting system against an Oracle back end. Nice, so you know Oracle? Great! What does "SELECT" mean in SQL? You didn't run into that bit of arcane knowledge? How did you write those reports? Oh a contractor set them up. But you did some data analysis? Oh a "team member" did that...

Am I alone in feeling that resumes are useless? That junior developers can't be judged by resumes because they have nothing to say yet and that senior developers can't be judged by resumes because after 10 years everyone can say the "right things" on paper?

Apparently not! Take it Seth:

Great jobs, world class jobs, jobs people kill for... those jobs don't get filled by people emailing in resumes. Ever.

Chime in Joel:

The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.

It's everywhere. Almost a meme. What did Warren Buffet have to say in the latest Berkshire Hathaway annual report? (highlights)

Charlie and I are not big fans of resumes. Instead, we focus on brains, passion and integrity.

OK but wait, is this really fair? Maybe if you're applying for some cool position but what about getting a regular job? Well yes, if you want a regular job it might work to approach things in a regular way. If that's what you want. Is it?

What's stopping you from having a completely different perspective on the resume-and-cover-letter strategy? Are you afraid the HR department will toss any resume that doesn't match their acronym pattern? OK, with many companies you're right. But do you really want to work for a company that rewards acronym-counts over interesting achievements? That values standards-compliance over unique accomplishments? That rewards professional conformity over personality and passion?

Seth sums it up wonderfully (my emphasis):

Having a resume begs for you to go into that big machine that looks for relevant keywords, and begs for you to get a job as a cog in a giant machine. Just more fodder for the corporate behemoth. That might be fine for average folks looking for an average job, but is that what you deserve?

If you don't have a resume, what do you have?

How about three extraordinary letters of recommendation from people the employer knows or respects?
Or a sophisticated project they can see or touch?
Or a reputation that precedes you?
Or a blog that is so compelling and insightful that they have no choice but to follow up?

Some say, "well, that's fine, but I don't have those."

Yeah, that's my point. If you don't have those, why do you think you are remarkable, amazing or just plain spectacular? It sounds to me like if you don't have those, you've been brainwashed into acting like you're sort of ordinary.

We called him Tortoise 'cause he taught us!

We're interviewing for junior software developers right now. I've just completed about 20 phone interviews and the lack of useful experience is appalling.

Let's not rehash the arguments about what is "computer science" and how to hire and about how most people are no good and all that.

I'm not even talking about how smart they are. I'm just talking about the coursework.

It's time for "computer science" to become "science" and not math. Meaning: Learning to use the tools and techniques of the trade, not just formulas and mathematical analysis.

For example, of the 100 resumes and 20 phone interviews I've done in the past month:

• 3 have ever used a version control system; only 1 of those could describe what version control is.
• 5 even claimed to know anything about SQL; none of them could tell me what an "outer join" was.
• 6 have ever done a unit test; zero had ever done a unit test in school.

I can't understand why, for example, "SQL" isn't a required course. I'm not asking for much -- OK if you want to emphasize the mathematical properties of queries, OK if you want to teach data normalization theory. I'd prefer practical things like "never delete data" and "auto-increment versus GUID's" and "how to diagnose slow queries" and "how database vendors differ," but I'll take anything at all where they could at least form basic queries and know roughly how they work.

Even "unprofessional" open-source projects all use version control. The vast, vast majority of software companies do too. Version control is almost as important as the compiler. I'd be happy if there was a course where you learned things like branching theory, but I'd be content if they just used it at all, at any time. Schools love group projects, so how is it that the group project doesn't involve version control?

And no unit testing? Ever? That's just lazy. Why is that not required for all coursework? By the way, if you required it, almost all assignments would be correct when they were turned in. Isn't it better to teach people how to make sure they always get an 'A'? How is unit testing now on par with how to debug?

Which is another thing. I never had any instruction on how to use a debugger. To me that should be an entire class -- how to find out what's wrong with code, especially when you didn't write it. And unit testing should be a part of that.

I can think of two reasons why these obvious things aren't taught:

1. Professors don't know these things either because they don't keep up with new trends and practical processes. Of course I'm making a wide, unfair judgment, but witness for example the slow acceptance of Java.
2. Departments don't want to "sully" their pure, theoretical, artis liberalis culture with practicalities. Analogy: The math department is mostly theoretical. If you want applied math, be a physicist or an engineer. My problem with this is there is no alternative. OK, so have a theoretical computer science degree, but then where's the "engineering" alternative? Some colleges have this concept, but for example at UT the alternative just meant fewer hard CS classes, not more practical classes.

Oh well. From what I can tell it's the same in a lot of disciplines. Most of the MBA's I know can't run Quickbooks or read a P&L, and the ones that can tell me they learned it on the job.

OK, I like on-the-job learning, it's the best kind, but throw me a bone. At least broach the concepts somewhere in the 4-5 year curriculum.

We Won the Jolt Award!

For those of you who don't spend 80% of your lives in front of a compiler, the Jolt Award is the Oscar of the software development world.

Code Collaborator just won the 18th annual Jolt Award in the category of "Collaboration Tools." We beat out some excellent competition including Atlassian's Confluence and JetBrains' TeamCity.

Now, before you ask...

Yes, that's a real 24-ounce can of Jolt soda.

No, Jolt is still in business and still sells the cans in some places.

No, real soda would explode in the process of being encased in Lucite, so the can is tapped, drained, and pumped full of silicon, which makes the whole thing really heavy.

90 grams of sugar.

Yes, I'll report back on how winning the award affected our web traffic and download numbers.

The thanks goes to everyone at Smart Bear for not only creating an incredibly successful product, but treating our customers so well that our message becomes news and a story and not just another product at another company.

Using fear to discover what's important

One of the biggest fears in a software company is that their source code could be leaked. All secrets revealed! All that trial-and-error and long hours with customers and careful planning... the results of that effort are now sitting on your competitor's desktop, free for the taking.

Although we know it probably wouldn't make a difference, investigating this fear turns out to be a valuable exercise

When you cringe thinking of your next open-source competitor having your source code as a starting point, what specifically comes to mind?

Surely not all your source code would help them. Some of our code is seriously bad news. I would wish this code on a competitor.

Besides that, a lot of our code is not interesting or can already be pilfered. The code that lays out our HTML? You can see that using "View Source." Our method for moving data between Java objects and the back-end database? Who cares, everyone uses Hibernate. Our web-application architecture? Who cares, nowadays everyone should be using different architectures that were built from scratch to live in a DHTML/AJAX world.

So what would I actually worry about?

Here's one. Our version control integration library is built from five years of hard-won experience in the field. There are so many corner-cases and combinations of configuration. It represents thousands of man-hours. We have thousands of unit and integration tests, most of which using data that came from the field. Our advanced integration is unique in the market and is used by every one of our customers, so giving up that insight to a competitor would hurt.

There are a few other things, mostly complex, optimized algorithms. But what's amazing to me is that the overwhelming majority of our code could get leaked, and it wouldn't help a competitor.

I'll bet if you're honest about your own project you'll find the same.

Implications

1. We're by far the #1 product in our market, even though almost none of our code is "secret sauce." Maybe having "secret sauce" isn't nearly as important as execution. Maybe your customers are interested in how you treat them and whether you're implementing features they need, and not interested in how much work it took to write the code. Maybe it's more important that you can get eyeballs to your website and that your website gets people to download, and not so important whether you have a patent on something.

2. We should leverage our uniqueness in marketing material. I just identified the parts of our code that make us unique and where our competitors are not likely to catch up quickly. "Secret sauce" in code can point the way to market differentiation.

3. We could be spending less time on the stuff that isn't "secret sauce." You have to be careful with this rule because it would be easy to say, for example, "Because the layout of our website is easily copied, we shouldn't spend time coming up with a great layout." Dead wrong!

Here's a better example: We rolled our own web application framework because we felt it would give us a leg-up in certain ways. But in retrospect, the framework ultimately didn't do anything that special, certainly nothing that a customer would care about. Before embarking on a large, time-consuming project that could be satisfied by a tool or library, consider whether you're truly adding "secret sauce" that will give you a leg-up, or whether you just felt like reinventing the wheel.

4. Perhaps it would be useful to employ selective obfuscation. Whole-project obfuscation is at best a pain and at worst can create bugs in code that depends heavily on introspection and dynamic loading. And this exercise shows that it's not that useful. But there are certain places where it is useful, and obfuscating a small number of well-understood classes is easy and relatively safe.

Free for all

What would happen if tomorrow we made freely available all the source code to Code Collaborator?

Can you imagine Intuit releasing the source code to Quickbooks? Or EA Sports handing out the code to NHL 2008? Even cool companies like 37signals go so far as to encrypt their hard drives against theft of code.

Most software companies would consider such a thing contrary to everything they hold dear. But sometimes it's worth challenging assumptions.

Why not?
So what are the specific reasons to not publish our source code? What are we afraid of?

Well this should be easy...

Competitors catch up to us quickly because they can easily copy everything we've figured out how to do: Cool AJAX/DHTML techniques that they don't have; Super-smart file-differencing algorithm; Interfacing with 7 version control systems while handling all the corner cases.

We show them the way, they catch up, and suddenly we're neck-and-neck instead of keeping our lead in awesome features.

Support becomes impossible as customers make arbitrary changes to the code. They could change anything -- from benign things like CSS styles to introducing a subtle bug in application logic. It's hard enough to track down problems in the field without "all the code" being a variable!

Besides supporting bugs, you know we're going to get source-level support questions. Yeah you can say "we don't do that," but it's going to happen and it's hard to turn people away.

Potential customers scared away after seeing the state of your code. You laugh, but it's a valid concern. Much of our code is well-documented and well-tested. But some isn't. Some is downright embarrassing. You never know what someone else's impression might be.

Yeah, but not so much. Apparently all these fears are unfounded.

Here's my disconnect: There are small companies just like us who publish all the source code to their software, and none of these concerns are a problem for them.

Take for example the issue-trackers JIRA (Atlassian) and Fogbugz (Fogcreek). Both are in an insanely crowded space with fierce competition ranging from open-source to small-company closed source to big-company software/services.

And yet, both are popular even with the fear of competitors stealing secret sauce. Both are highly profitable, not buried under a mountain of technical support. Both have ugly pockets of code, but I've never even once heard anyone mention that as a downside, not online, not in the field, and certainly not as a reason to choose a different product.

So what's the explanation?

Ummm, just because?
All the following are theories. I honestly don't know the answer.

To me the biggest upset is in the assumption that competition automatically gets tougher. Here's some possible reasons why it doesn't:

1. Writing an algorithm is just the start. So let's say a new competitor steals our awesome, optimized, unique AJAX/DHTML code for real-time, context-sensitive chat. So now we're even? Well it doesn't matter until a potential customer is checking them out, which means executing on marketing and advertisement. And it doesn't matter if during the trial we give the customer a personal demo and responsive tech support while the competitor asks him to post a question on a forum. And it doesn't matter if all they can claim is that they're "the same." All else being equal, most people will go for the incumbent, proven, most popular tool, which is us.

2. Competitors need to differentiate. Even if you could be just like another product, you don't want to be. Sure you might pick up some ideas for algorithms here and there, but that's not enough by itself to sway potential customers.

3. Developers like doing things their own way. Every good developer I know wants to write code herself. Yeah you might pick up some ideas but your first reaction to almost any code is that you could write it better, organize it better, document it better, make it more flexible, whatever.

4. Most code is not reusable. Almost all our code depends on assumptions, design, and other code that is relatively unique to our product. Sure we have some utility classes that could be copied and reused, but those are the kinds of things that are easy to unit-test-to-hell which means it's not hard to reproduce it even without our source code.

5. Serious companies don't steal. Any serious competitor will have internal rules about stealing code, even if it's an open-source project. Once again, little tricks here and there could sneak in, but not wholesale copies of libraries. A serious competitor has too much to lose -- revenue, customers, possible future upside -- and if that comes out it's all over.

The other two items are easier to understand. Support can be kept in check:

1. Most people won't change the code.

2. Limit support on source code changes. Your customers will understand that you cannot provide unlimited support on that front, so you can just pick and choose how much time to spend helping someone. It's no worse than a competitor who is closed-source.

3. Include a "source changes" report in tech support reports. We have things like verbose logs, config files, and diagnostic pages, so just add something that tells tech support what, if anything, has been changed by the customer. If something has been changed and you cannot reproduce the issue, you can now reasonably deny tech support unless they can reproduce with a clean installation.

So... are you going to do it?

Nope. :-)

But I know that he knows that I know

When two people in America need to make a boolean decision and a coin isn't available, the go-to method of problem resolution is probably Rock, Paper, Scissors.

Generally people feel this game is fair, meaning there's an equal likelihood of each participant winning, losing, or tying. And of course if you're an academic who believes Big-Oh embodies everything you need to know about algorithms, you might leave it at that.

But we real geeks can never leave things at that. And I don't (just) mean playing Bear, Ninja, Cowboy:

Cowboy beats bear, bear beats ninja, ninja beats cowboy. The theory behind this is that cowboys can shoot bears but are not fast enough to prevent a ninja from assassinating them, but a bear's acute sense of smell prevents the ninja from gaining the element of surprise, thus allowing the bear to maul him. --Wikipedia

So....

The UK-based Telegraph tells us there's a strategy that wins more often than 1/3 of the time:

Research [from the New Scientist] shows that stone, also called rock, is the most popular of the three possible moves in the game.

That means that your opponent is likely to choose paper, because they will expect to you to start the game with stone.

By going with scissors, you achieve an early victory.

But hold on. If rock is the most popular move, going with scissors means you would be defeated. But here it says you'll win. Which is it?

It depends on what your opponent knows. Let's first assume that neither player knows anything about the statistics or analysis of RPS. (Yeah, RPS is not only an accepted acronym, there are even RPS tournaments. Wowzies.) A and B are innocent players, but we want to give A an advantage.

The new study says that, unbeknownst to the players, rock is the most popular move. That means ignorant B will throw more rock than average, so A can win by throwing more paper against it. So we should whisper into A's ear that he should throw more paper.

But what if B has read about this new study? His "beknownst" state has flipped to true. Then we expect B to favor paper, so in this case we should instruct A to favor scissors.

Ah but it gets worse, as it often does with these things. What if B knows that A knows that B read the study? Then B will figure out that A will favor scissors, and will start favoring rock again. Double-fake!

But you see what's coming next. If A knows all of this, A can double-fake too. And so on.

So where does all this leave us? That, at least in regard to this study, he with the most information wins. There's probably a life lesson in there somewhere.

Another life lesson is to always keep digging. Like, this isn't even over yet. One strategy is to call out what you're going to throw, and then actually throw it. The theory is that the other person generally won't believe you. Why is this an advantage? Let's take a concrete example.

A says, "I'm going to throw rock." Let's go with the theory that B doesn't believe it. So B thinks A will throw paper or scissors. If B throws rock, he figures 50% chance to win, 50% chance to lose. If B throws paper, it's 50% to tie, 50% to lose, so that's no good. If B throws scissors, it's 50% to win, 50% to tie. Add it up: B's best move (under his assumption) is scissors, and second-best is rock.

Since A will actually throw rock according to this strategy, and we figure B will throw rock or scissors, A will either tie or win. Awesome!

Until B knows that strategy, of course...

Which leads to the final point, which is that Wikipedia and the ideals of the open source movement of freedom of information has crept far and wide.

Take another look at the image at the top of this post. Nice, right? I didn't make it, I stole it from Wikipedia. It's legal because Wikipedia is good like that. But wait, who made that image? It turns out each of the pieces were stolen from other Wikipedia images and composited together by a guy known to us only by "TheCoffee." Thanks, dude.

Oh, and take another look at that Telegraph article. They stole the image too. Except they didn't credit Wikipedia. They didn't even link to the larger version of the image. Nice, guys.

Freedom at the cost of anonymity.

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.

December Dumbass

Don't be a schmuck.

This is Jackie Mason's advice about financial investments. Or how to buy a suit. Or how to treat your mother. I think it's his advice about everything.

He's right. Especially about software release dates.

In my infinite wisdom, last year I decided we needed to release Code Collaborator v2.0 at "the end of the year." This was brilliant because: Since everyone is on vacation at the end of the year, the office will be relatively quiet and we can get the release done.

What I didn't consider was that we would be on vacation too. And that the customers who we imagined were anxiously awaiting our release were also on vacation.

So after killing ourselves, and slipping to Jan 20 anyway, turned out no one cared. We cared about our deadlines much more than anyone else.

Even when you have people waiting for a release, remember that they'll upgrade when it makes sense for them. If you're in the middle of a release cycle, you probably won't spend the time, take the risk, and get retrained on an upgrade. We're the same way -- a new version of the profiler we use came out during our 2.0 crunch, but there's no way we had the time to mess with it then. Even if it's better.

So this time we released v4.0 beta on Oct 1, and we expect to exit beta before the end of the year. But if we don't, we don't care!

Bears Again!

In the latest issue of SD Times the bear lives on! This is a scan of the newspaper. That's Brandon in the background.

This continues the saga of the bear.

Editor-in-chief David Rubinstein wrote a great piece on doing code review and had some nice things to say about us.

Full issue in PDF is here; we're on the cover, on page 26, and on page 42.

You're a real company when...

Ever since I started Smart Bear, there's been a running question of "When do you know you're a real company?"

Which of these are true: You're a real company when...

• You have a domain name that isn't weird.
  
• Your business cards don't say "VistaPrint" on the back.
• You take PO's in addition to credit cards, and you've gotten over the fact that, yes, you have to actually ship the product before they give you money.
• You have to switch from Quicken to Quickbooks.
• You hire the first real employee.
  
• You pay someone else to print pay stubs and pay your monthly employment taxes because you're just tired of doing it yourself.
  
• You have a sign on the building.
• A real artist does your website and handouts.
• You have a 256-page color glossy hard-backed book chronicling your ascent in the world (Saw this at Adobe. Gorgeous. I asked everyone I met there about it and no one but the receptionist had ever seen it. It's sitting in the lobby. The receptionist, by the way, knew exactly what their branch of Adobe (Ottawa) did and could articulate why people bought it in about 15 seconds. Her elevator pitch was better than the 10 minute diatribe I got from a senior manager later that day.)

I made one of those bold because that's the one I think has always stuck with me. We got the sign about a year ago, and it really was a proud moment.

Currently Smart Bear has everything but the glossy book (but we do have a book with a glossy cover with over 7000 copies in circulation). The 8000'th user of our various software products just came on-line. That makes me feel like a real company.

Guy in a bear suit

Does your company have a mascot? Ours does. And ours writes Eclipse plug-ins in addition to being a fearsome beast.

Not that I'd normally call Roy fearsome. Formidable, yes, but not fearsome. He juggled flaming clubs on Brandon's wooden back porch ("Don't worry, it's just fire"). I once saw him fixing an obscure bug in our Subversion/Eclipse integration while wearing the complete bear outfit.

So what happens when you put an Eclipse developer in a panda suit and stick him in the aisle at SD West?

1. Everyone notices.
   
2. Most people gravitate to the bear. Gotta see what this is all about. Usually they are smiling.
   
3. A few people will do anything to avoid getting close to the bear or making "eye contact."
4. People assume you've hired some poor high school student to stand around in the suit. So when the bear engages you in a discussion of peer code review you might be surprised enough to actually talk about it.
5. The bear's position in the aisle in front of the booth was unintentionally brilliant because: (a) you have to walk around the bear -- the suit plus personal space creates a significant no-fly zone, plus (b) there was always a crowd around the bear, checking it out, seeing if it could talk, which increases the no-fly zone, therefore (c) if you want to get past the bear you must swing all the way to one side of the aisle (where our booth was) or the other, so (d) you end up getting our pitch and seeing our stuff even if you avoid the bear, especially since (e) the leftover space between bear and booth was so small that it created a logjam so you'd be standing in front of the booth without ability to move so you might as well check out our movie and get a free book.
   
6. At least 10 other vendors at the show commented that "That guy must have lost a bet." Sheesh. Roy really wanted to be the bear, and he was really good at it. He spent a lot of time in the bear head back at the office to get used to where the ears and head and eyes and chin were.
7. If you cup the vestigial ears and bend them forward and say "come again," no one considers that this action doesn't actually allow the human to hear better.
   
8. Not-so-clever Stephen Colbert references abound.
9. Once the bear was propositioned. A woman commented that it would be great to have a bear mow the lawn. Roy said the bear was not for sale, but I thought he should have at least heard her out. Everything can be had for a price, even a mowing bear. Maybe not for Roy.
10. Bears stand out at awards shows. Craig (as in, he has a list) mentioned the bear three times during the ceremony. Eric points out it worked because Roy was not jumping around, calling attention to himself. He was just calmly sitting there, as if it's normal that a bear would be attending the Jolt Award. Which, of course, it is.

P.S. Before you put 2 and 2 together, it turned out to not be a juggling bear. Roy couldn't see well enough out of the... neck... to juggle. He actually got three balls going by throwing them back on his furry belly to reduce error, but it looked weird.

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...