A Smart Bear

Ideas for Swarm

2008-10-12T10:03:00.003-05:00

For this episode, a little less marketing, little more geek.

Ian Clark has some interesting results with a new distributed programming language called Swarm. As the founder of Freenet and other large-scale computing systems, his opinions on the subject are not idle thoughts.

He does a fine job of explaining Swarm with preliminary results, so I'll limit myself here to a pile of off-the-cuff reactions:

If keys in the store are an MD5 or SHA1 of the content they are storing, caching data across nodes becomes trivial. If stack state is stored like this as well (compute only on send?) and chained (one stack frame per hashed data element, each with a "pointer" to the hash of the next stack frame), transmission of continuations can also be saved.

The graphics are the compelling thing. It's what separates this from other projects. Emotional? Yes but adherence to a programming language is as much emotion as anything else. I say build visualization into the language itself. Make it trivial to produce. This is what everyone's going to share and talk about.

Use the JVM model; don't invent a new VM. But you need full control. So, start with a JVM interpreter written in Java (see joeq or jikes or write your own using ASM) which you could then modify. Then you inherit all existing Java libraries to your new language. You have to inherit a bunch of libraries, at least at first!

This also opens the door for interesting optimizations, like identifying short stretches of bytecode where break-for-continuation is not permitted, breaking those out into dynamically-written subroutines, and allowing the underlying JVM to JIT it.
Scala might be fun to learn, but if this project gets going it will be hard enough to root out the bugs without the underlying language also riddled with bugs! Not to mention the extra barrier to entry ("Wait, I have to learn Scala first?").
How does user interaction work when the execution is moved? Even something as simple as a command-line, much less a GUI. Doesn't this imply that at some point in the execution stack you have to return to the original machine?

(More reason to use Java directly -- bridge between distributed-mode and local-mode for the non-distributed part of the work.)
Same question with external resources. File system is easy, but what about a TCP connection or a database connection? How shared across machines? Or do you need a way to say "Send the execution to this specific node, the one that houses this resource?" Maybe with an instruction that says "When this routine completes, redistribute this execution." Maybe that instruction has a back-pointer to the original executing node, not requiring you to return there (i.e. what if that node is now overloaded?) but suggesting since that node does have all the necessary data cached.
In Java some critical, tight, high-performance routines are in C; in Swarm perhaps tight routines can be in Java! Java Annotations might be a way to specify "don't distribute" on a method.
If you base on the JVM and use Annotations, perhaps existing code could be ported with no alteration! Or you can mix Swarm and plain Java with one line of code. This "easy to revert back" attribute is critical for adoption because people don't like lock-in.
How does synchonization work? Locks-held need to be part of the continuation. But are there other subtle issues?
You'll need your own synchronization of course. Please please please use deadlock-detection, throwing an exception instead of just locking up. It's not hard to implement.
Suggestion that MapReduce be the next thing that is implemented because it's the hot thing in distributed computation and folks are convinced that many useful things can be expressed that way. Demoing efficiency (and pretty pictures) here would be compelling to many people.
Fault tolerance. Probably don't have to have this at first, but need a thought-experiment-level concept of how to handle.
Computational caching. With SHA of input and full knowledge of bytecode, you could perhaps automatically cache the results of computation! Think of algorithms where you should use functional programming. Or even just dynamic webpages where the home page doesn't change that often.
Consider JavaSpaces for object transfer? Might solve some issues with fault tolerance.

Giving advice and asking questions is easy. Hopefully some brave souls will do the real work of getting Swarm up and running. Good luck Ian!

Giving it away

2008-10-08T21:46:00.000-05:00

In The Coldest Call, Gerry Cullen gives us an pithy rule of sales:

If you can't give it away for free,
you can't sell it.

It sounds tautological at first, but it helps you create products that are easy to sell. Here's how.

Because of Smart Bear and this blog, I hear new company ideas all the time. When I start asking about new products, the conversation invariably looks like this:

Me: Would you get customers if your software were free?

Confident Entrepreneur: Of course! Why not take it if it's free?

Me: That's what I'm asking -- are there reasons people still wouldn't take your software even if it were free?

Confident Entrapreneur: Free is free. Of course they'd take it.

Not so fast there, pardner.

Let's say it's 1998 and you've invented a corporate-wide spam filter. Great timing -- the web is exploding, everyone has an email account, spam is choking in-boxes and wasting time. You've invented a box that sits in front of the mail server, tossing the garbage before it hits your server, much less your workstations and laptops.

So couldn't you give away a free spam filter?

Well. What happens when the filter accidentally marks something as spam when in fact it's a real email? Will we lose productivity as people get confused or spend time digging through a massive spam dumping ground looking for the message? Does email recovery require an administrator? Will he be drowned in requests? Will we have to hire a spam depository admin? Operating this system clearly costs time and money.

How much training is required to get people to use the new system? How many spam-filter-related questions will hit our internal help-desk? Support activities are expensive.

What if the spam filter box gets overloaded with too much mail? If there's a bug, is it possible to loose an email completely? What happens if the spam filter box crashes -- does email cease across the entire company? Losing email is unacceptable.

These concerns are so scary and costly that the spam filter might not be worth it, even for free. And if you're ambivalent about taking it for free, you're certainly not going to pay for it.

So how do you design a product that passes Gerry's test? Ask yourself brutal questions to root out how your product might cause more pain than it solves. Here's some to get you started:

If your product fails catastrophically, what's the impact?

Good answers include:

Because the product is completely independent of any other system, in the worse case you're back to how things were before you bought our product.
We'll show you how to configure other systems to silently and automatically route around the failure. During the trial period you can test this yourself.
We have built-in support for switching back to the way you were doing it before.
Administrators are instantly alerted of the failure
You can use your existing monitoring/alerting system to detect failures
We support live-redundancy and continuous backup

Is it easy to rip this out if I don't like it?

Good answers include:

Since this system is completely independent of all other systems, you can just turn it off.
All data in the system can be exported at any time in a standard, human-readable format (e.g. XML, CSV). (You can also use this for backup.)
Because we handle catastrophic failure gracefully, you can literally pull the plug and everything else continues to work.

How much training does this require?

Good answers include:

Our website has pre-recorded training presentations. We give you the source materials for free so you can customize for internal training classes.
We have tutorials and screenshots showing how to do common tasks.
We have excellent in-product help, as well as a printed manual.
Accomplishing typical tasks is obvious.

Can my end users inadvertently break the product or prevent other users from using the product?

Good answers include:

Each workstation is separate so it cannot break other people's workstations.
The server has quotas, permissions, and other administrator-controlled limits to prevent excessive or improper use.
We support running inside a virtual server so our software failures are isolated.
We blast our software with load-testing, failure-case testing, and intrusion-testing, so we know that users can't break it with normal use.

If your company goes out of business, what's the impact on me?

Good answers include:

Because you own the software/hardware and you host it yourself, inside your firewall, you're not affected.
Because your license code is good forever -- only upgrades require you to give us more money -- the software continues to work.
Although we charge a monthly fee, the license agreement states that if we go out of business you can continue using the software without charge.
We'll put our software in escrow so if we cease support you have the ability to maintain the product yourself. (In this case it's reasonable to require the customer to pay all escrow costs.)
Our software is open-source and licensed such that you can continue using it and changing it. (This works if you're selling professional services.)

With these questions in mind, here's some ideas for tweaking the corporate spam filter product:

The filter runs as a plug-in to your existing mail server. The email admin therefore has full control over when it runs, making it trivial to disable.
If the plug-in fails it makes a log in the mail system which can then be monitored by the same tool that already monitors the mail system.
Because it's a plug-in, it scales as your mail server scales.
Users get one email per day summarizing the mail that was marked spam. They can glance over it looking for things that are not spam, and use a link next to each one to recover it, in which case it's instantly delivered to their inbox. Thus they can help themselves most of the time without burdened email admins.
The summary email can is clear enough that most people will understand it without training classes.
Spam emails are stored in a special folder in the mail system, not in a proprietary format. Then data access and backup can be done with any email client, even if you uninstall the spam filter, even if the supplying company vanishes.

Does your product pass Gerry's test? Want to brainstorm about it? Leave a comment and let me know.

Customers over Employees

2008-10-04T14:46:00.000-05:00

Alex Kjerulf articulates why customers can't always come first.

Let me get this straight: The company will side with petulant, unreasonable, angry, demanding customers instead of with me, its loyal employee? And this is meant to lead to better customer service?

Everyone says "put customers first." They pay the bills, they're who the company exists to serve, they're the ones who must be satisfied, in their hands rests word-of-mouth, the most powerful force of marketing.

But what about employees? The ones who you'd like to be motivated to serve these customers, day in and day out. Where do they fit in the customer service model? When it comes down to employee happiness versus customer happiness, what do you do? And yes, it can come down to it.

Some customers are so poisonous to your poor employees that it's your duty to get rid of them. Some you should wish on your competitors. Sometimes the customer isn't right.

Maybe 1% of your customers are problematic, but they're a vocal and time-sucking and morale-draining 1%. Is 1% more business worth it?

Peer code review interview at GeekAustin

2008-09-27T14:26:00.002-05:00

Lynn Bender is getting really good at interviewing!

He just posted a recent interview with me about why peer code review works and how it fits with modern software development.

If you haven't been to one of his mixers, you should stop by the GeekAustin 8th Anniversary party this Tuesday. He always throws a great party.

Joshua Bloch dripping with wisdom

2008-09-23T18:23:00.001-05:00

When Joshua Bloch speaks, the ground shakes, oceans part, and Java developers fall to their knees and tremble. At least, I do. I think animals get nervous before Josh writes articles.

His latest article on API design is a must-read. I don't think he's written a single word I don't agree with, and this is no exception.

P.S. If you're a Java developer and you don't have Effective Java within arm's reach, consider it a critical-severity bug in your personal development. The Puzzlers are less practical but fun.

Software Quality Mortgage

2008-09-07T14:20:00.002-05:00

Your code is a mess. Years of squeezing in "must-have" features for big customers have stretched the code beyond its original design. Core modules are riddled with landmines. Tacit assumptions shared by the two founders aren't obvious to the next ten hires.

When companies are new and unknown, still seeking their niche, the most important thing is to get the software out the door, bugs and all.

It's the right thing for the company and the right thing for the software, but there comes a day when your emphasis shifts from "time-to-market" to reducing tech support calls and not pissing off tens of thousands of existing users with a dud release.

But now you have all this crappy code.

I call this phenomenon the "Quality Mortgage." The analogy to a home mortgage is instructive.

A responsible, hard-working person still cannot afford to purchase a home outright and therefore enters into debt. If shippable, salable software is the house you want today, your debt is the quality and maintainability of your code. Sure you could build a close-enough-to-bug-free application if given ten years to work on it, but you're taking out a mortgage to build v1.0 in six months.

But eventually you have to pay back the debt. With interest. You pay interest in the form of bugs. Bugs everywhere, many preventable had you given time to have unit tests, good design, manual tests, and use-cases. And fixing those surface bugs doesn't fix the underlying problems in the code. This is perfectly analogous to those first years of the mortgage where you're paying interest without reducing the principal. But this is still the right choice at first -- fix the most heinous bugs and keep going.

Over time you can pay back the principal, slowly. You can refactor one file while adding a feature. You can add complete unit test coverage for a handful of core methods. You can write a manual test plan for a particularly complex dialog box. This is all good! But at this rate it's still going to take ten years to pay it back.

Or maybe you'll never pay it back. Because unlike a house your software is constantly expanding with new features and reused for purposes beyond its original conception. Without fixing the underlying mess or the process that brought you that mess, you'll never catch up. It's more like an interest-only mortgage.

At some point you can't tolerate this anymore. It's time to pay down the principal in earnest. But this requires allocating time for major rework.

Winning the right to refactor can be tough politically, especially with non-technical stakeholders. Here's how to combat the common arguments against spending time refactoring:

Clean-up is invisible to users; we need to add new features.
The bugs constantly produced by messy code are visible to users too. Time spent fixing those bugs could have been spent adding features. The longer we stay in quality debt, the more time it takes to add each new feature.

We don't have time for clean-up.
You'd rather spend your time fixing bugs generated by the problem rather than fixing the problem? That's like whacking weeds every weekend instead of pulling them up by the roots. Prevention is sixteen times more valuable than cure.

Developers got themselves into this mess; they should get themselves out of it on their own time.
Had developers not gotten releases out the door as fast as they did, had they not responded so swiftly to early adopter feedback, even when the product morphed into a beast quite different from its original conception, we wouldn't have our current customers and revenue. We'd be working for another company, not complaining about the software we built.

Attention CEO's: Finger-pointing impedes resolution. Instead, challenge your developers to reduce bug reports. This is easily measured, so you can track time versus results. Remember, developers prefer implementing new features to fixing bugs, so if they're begging for time to fix bugs, it's serious.

A fine line separates debt as a lever for acceleration and an insurmountable drag. The quality mortgage is a necessary evil in early software development, despite its eventual problems. Just plan on paying it back.

P.S. After writing this I found Martin Fowler making the same point.

Avatar Marketing

2008-08-20T19:55:00.001-05:00

Addressing your entire customer base at once is tough, but it's exactly what your web page has to do. Unfortunately most companies approach this in exactly the wrong way.

Examples of our struggle:

We want managers to see that they'll get metrics and reports, but we want end users to see that they'll save time and busywork.
We want to look professional so big-company managers are comfortable choosing us, but not so aloof that small-company developers think we're too corporate and can't relate.
We want to highlight our configurable workflows that allow large customers to apply one tool for all groups, but we need small customers to realize that you can turn all that off so it doesn't slow you down.

The usual response to this conundrum is to cast a wide net. The worry is that if you hit one type of customer on the head, another type will feel excluded and might look elsewhere. So you use generic messages like "The Power to Know."

This is dangerous thinking. Generalized messaging has no power, no emotional connection, no interest. If a phrase like "The Power to Know" is equally useful for business intelligence software, buying decision analysis, and theosophical treatises, it's not exactly hitting the nail on the head.

Let me suggest a completely opposite approach. Start by describing a perfect customer. Give her a name (Carol). Pick a concrete company that she works for, a company similar to one of your existing, thrilled customers. What's her official title and what does she do? If your potential market includes a wide variety of company types and positions, just pick one in particular. Whatever problems your product solves, Carol has all those problems. Write those down from her point of view, the way she would describe them if complaining to a friend over lunch. Whatever advantages you have over your competitors, Carol needs exactly those things. List them.

Carol is literally custom-built to be blown away by your product.

Now the question is: What would a web page / Google ad / print ad / tradeshow booth / postcard be like such that Carol would immediately understand that you are her savior? Remember, you get only 3 seconds to grab her attention and another 5-10 to convince her that your product is the second coming.

Can you make it clear in a picture? Maybe a before/after she can relate to? Will describing three features make it plain? Will pointing out your best competitive advantage make her weep for joy? Can you ask a provocative question, something she identifies with? Is there a phrase she'd laugh out loud at because "that's so true?"

You only get a few seconds, so a paragraph won't do. You have to communicate in a picture and a few words. The good news is you have to please only Carol, and you know Carol. You even know she'll honestly be thrilled to find you.

If your ad can't grab Carol's attention -- your perfect customer -- why do you think it will grab anyone else's attention?

If you still say it's impossible to communicate your message in 5-10 seconds, no one in the world will get your message.

This isn't just an academic exercise; your ad will work on non-Carols too! In fact, non-Carols might not be as "non" as you think:

So called "large company managers" might be running small agile groups; you might do well to appeal to that side of them. Software development managers might like metrics, but it's wrong to think they are unconcerned with their developers' quality of life. Yes big companies like to choose "stable" vendors, but small companies with strong products are in vogue now, and even IBM admits that people can be fired for buying IBM.

When your message is powerful, Carol and anyone remotely like Carol will notice. If your message is weak, no one will notice.

Wordle me this

2008-08-16T08:15:00.000-05:00

Wordle is fun!

(Click to Enlarge)

It's also instructive. It's clear I write more about marketing and business than about software development. I didn't intend that at the outset, but there it is!

Hello, I'm 1074018628

2008-08-07T11:08:00.003-05:00

I just received this email:

Yahoo! is committed to the success of account 1074018628 and we believe there is an opportunity to provide you with improved performance.

There's saying you value your customers, and there's your behavior.

You can use your customer mailing list to barrage me with up-selling "opportunities," or you can send me interesting articles.

You can put your customer service number on every page on your website, or you can provide only a web form.

You can have a recorded message saying my call is important to you, or you can have someone else pick up the phone.

You can answer the phone with the least knowledgeable, lowest-paid employee you can find, or you can empower service reps to give refunds, bend the rules for extenuating circumstances, and escalate special situations to someone who has the power to address them properly.

Is "customer service" a service for customers or a shield against them?

Actions > Words.

The customer is always right?

2008-08-01T13:59:00.002-05:00

"The customer is always right," coined by somebody around the turn of the last century, is probably still a good mantra for retail, restaurants, and the like.
But many of our customers are the opposite. In fact, many hope that we'll tell them what's right.

During every demo there's a moment where the customer explains how they're going to do X in their process, and how Code Collaborator seems perfectly suited for X. Then, much to their surprise, I gently explain why X is a bad idea and Y is better.

Sounds arrogant, right? The customer is always right! And they were happy about X and happy that we would support X, so what the hell am I doing? Let 'em be happy!

What I'm doing is enabling them. I'm giving them advice from years of experience for free. I'm demonstrating that we tell the truth, even if the truth doesn't serve the direct purpose of selling the tool, even if it means I'm arguing instead of agreeing. And it's appreciated, because there's not enough truth in sales and business.

Of course the customer isn't always right, and with some types of business you should roll over. If you're runing a restaurant and a customer thinks a barely-red steak is "totally rare," just cook the crap out of it and give it back.

But if you're going to be an expert, be an expert. That means not just agreeing with everything the customer says, but genuinely helping.

Obfuscation

2008-07-24T08:10:00.001-05:00

I got a new laptop recently. The main advantage of the new laptop over the old one is that the new one wasn't run over by a car. Long story...

Anyway while I was selecting my wireless card I was accosted by this astounding product description:

Intel Wireless WiFi Link 4965AGN (supporting Centrino Pro)

The Intel® Wireless WiFi Link 4965AGN product is an embedded 802.11a/b/g/Draft N PCIe Mini Card network adapter card that operates in both the 2.4GHz and 5.0GHz spectrum, delivering high throughput and a host of features that enhance today's mobile lifestyle. Deploying WLAN technology in your home and business increases productivity, efficiency and flexibility by enabling faster decision making, reducing down-time, and enhancing employee satisfaction. Quad-Mode Solution for maximum flexibility: the Intel Wireless WiFi Link 4965AGN provides deployment flexibility and connectivity convenience by offering a quad mode (supporting 802.11a/b/g/Draft-N) product, which is capable of connecting to new "Connect with Intel® Centrino®" wireless N Access Points / Routers, but can also connect to any of the legacy Wi-Fi standards, 802.11a, b or g. Data rates up to 300Mbps offer major improvement over today's 802.11a/g products that deliver 54Mbps. This helps overcome network capacity issues, allowing increased simultaneous network activity for large file transfers, network backups, streaming video, multi-player gaming, VoIP and more.

Here comes a rant with an ulterior motive. The idea is to develop a strong editorial voice in your head. You have to take the red pen to yourself so snarky pricks like me don't use your product description as a subject of ridicule!

After a rote description of the product, the writer chooses to list benefits disconnected from features, benefits that would apply to any competitor:

Deploying WLAN technology in your home and business increases productivity, efficiency and flexibility by enabling faster decision making, reducing down-time, and enhancing employee satisfaction.

Furthermore, these benefits are non sequiturs. Wireless enables faster decision making? Really? Reduces down-time? How can that be -- wireless is notoriously less reliable than cabled networks.

And is it really necessary, in 2008, to explain the benefits of Wi-Fi? If I'm considering skipping the Wi-Fi card, will this text convince me otherwise? Because it means faster decision-making?

The true benefit of this particular device is buried in the last sentence: Support for the latest Wi-Fi standard means more data per second, which is useful in specific applications like "large file transfers, network backups, streaming video, and VoIP." That's more like it. Why did it take 168 words to get to the point?

But I can't criticize without offering a solution, right? After boiling the goo out of this text, here's my outline:

Supports four different Wi-Fi protocols, so it works in more places and takes advantage of the latest technology.
Supports the fastest Wi-Fi standard, so high-bandwidth activities work better.
The only card that supports the proprietary Intel N Access Point system

Get into the mindset of the skeptical. Be brutal. Every word counts. Challenge every sentence to advance the cause of either getting the reader's attention, communicating something specific and useful, or showing how you're a better choice than the other products on the page. Tie goes to the briefest.

The Benefits of Features

2008-07-21T07:15:00.001-05:00

Common marketing wisdom is: Benefits sell, features don't.

Benefits are what the customer wants; features are merely the means to the end. Customers are interested in "saving money" or "saving time" or being "easier to use;" features aren't interesting until the customer understands and wants the benefits. Everyone says so.

My instinct is opposite. But, not wanting to second-guess tradition, I've dutifully fought my instincts at the behest of marketing and sales gurus. Since the first advertisements at Smart Bear I've had conversations like this:

Guru: Why is this here: "Integrates with version control systems."

Me: That's one of our features.

Guru: Say I'm a customer. Why do I care that you integrate with those things?

Me: Well normally you have to collect files for review by hand, but with this integration we can collect the files for you. So a mundane, 5-minute task reduces to a few seconds.

Guru: So it's going to save me time?

Me: Yes, and doing it by hand is error-prone and it's boring and ...

Guru: OK, OK, but mainly it saves time.

Me: Yes, it saves time.

Guru: Fine, than that's the benefit. "Saves time." I don't care yet how it works, just tell me how it will help me.

Me: So that's it? Just write "Saves time?"

Guru: How about "Cuts 80% of the time out of starting a review." That will grab my attention.

We'd do this with each of my feature points in the ad. So what started out as:

Integrates with version control systems
Threaded chat in context with code
Automated metrics and reports

Turned into:

Saves time
Easier to manage than email
Eliminates manual tasks

Looking back now over the last five years and considering what worked best for us, this technique still doesn't seem right to me because these benefit statements eliminate the interesting, unique properties of our product. Claims like "Saves time," "Easier to use," "Automates tasks," these are things that almost all software promises to do. Although these might indeed be the ultimate benefits, it's the same message as everyone else. I suppose I could claim "Saves more time than competitor X," but is that really the strongest message I have?

I agree that customers are interested in end results. Furthermore they need to picture themselves using the product and achieving those results. TV advertisers have long recognized the power of visualization; nearly every TV ad shows someone using and enjoying the results of the product.

But statements like "easy to use" are completely unhelpful in visualization. Even if you trump it up as "Cut code review time in half," I still cannot picture how that's going to happen. If I'm already a skeptical person -- quite likely with our target audience -- I might not wait around for you to explain it.

If your potential customers are experiencing pain, they'll automatically see how the feature achieves the benefit. Our customers already know code review incurs busywork and can be a huge waste of time. If I say "Writes reports for you" or "Collects metrics automatically" or "Packages and delivers code with one click," it's clear that the benefit is to save time and help with chores, but now you can visualize exactly how.

Be specific and tangible about what you do, just phrase it so it leads automatically to the benefit.

Pecha Kucha

2008-07-19T20:13:00.000-05:00

As some of you have already noticed, I have the honor of being selected to give a Pecha Kucha presentation on agile marketing at this year's Business of Software conference in Boston.

Wow, that's too many links in one sentence!

If you're considering a career in running software companies, especially your own, go to this conference. The keynote speaker list alone is reason enough -- there's more wisdom in those heads and ability to communicate it to others than most business schools in America.

Surprised to find bugs?

2008-07-14T18:20:00.000-05:00

Code Collaborator just got a great review by game AI specialist Paul Tozour.

My favorite excerpt:

The ostensible reason for this process was to get more engineers familiar with different parts of the codebase that they wouldn't have had any exposure to otherwise.

What we found was far more surprising -- we uncovered an amazing number of bugs before they ever reached QA.

Furthermore, the bugs were coming from everywhere, not just the junior engineers. All the engineers, including all of the most senior developers, had plenty of room for improvement.

This seems to be a common theme among groups implementing a reasonable code review process for the first time. ("Reasonable" means not encumbered by heavyweight process.) We're always surprised that our code wasn't as good as we first thought.

Shouldn't it be obvious? Have you ever written a page of prose that couldn't be improved? That you yourself couldn't improve when you look back a month later, but that you friend could have found with a two-minute scan?

Writing code isn't different, nor should we expect it to be.

By the way, once you get used to having the safety net of fellow programmers catching all your little mistakes, it's scary to go back to isolation. You know the bugs are there!

Boiling waste and goo

2008-06-23T12:26:00.000-05:00

In his review of Code Collaborator for the Jolt Award, Rick Wayne wrote the best description of our tool I've ever seen:

Smart Bear's Code Collaborator exploits that synergy by boiling the waste and goo out of the code-review process, bagging you the benefits of many eyes on each developer's code while neatly sidestepping much of the practice's traditional friction.

No hats!

2008-06-11T19:56:00.001-05:00

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

We're on the same page

2008-05-11T09:34:00.000-05:00

Advertisements are typically designed to stand on their own. Expensive ad firms frame comps on black construction paper, focusing attention and emphasizing isolation.

But how would your advertisement stand up if it were displayed side-by-side with your competitor's ads?

This happens a lot actually. Your Google Ads are likely to come up next to competitor's. Product listings in catalogs and websites usually group products with their competitors. Magazine ads are often juxtaposed. Potential customers may even print out your website and physically place it next to your competitor's on their desk. In color.

How does comparative advertising affect your message?

In the age of user-driven information flow, you can assume that a person looking at your website is in the market for a product like yours.Therefore expending effort justifying your market space in general might be a waste of those precious few seconds when a person visits your website for the first time. Besides, extolling the virtues of your market validates your competitors as much as yourself.

Instead, what features (and benefits) does your product specially have to offer? What are your strongest claims, the ones your competitors have trouble competing against? If you're the fastest, explain how speed enables new features that would otherwise be impractically slow. If you're the most customizable, emphasize how your tool can support a process rather than dictating the process.

That's not to say you shouldn't address general market advantages at all. In fact, it's often possible to simultaneously fold general benefits into your specific ones.

For example, which of these ads is more compelling:

Relieves painful migraine headaches.
Relieves migraines faster than anyone else.

The second ad conveys both the general benefit ("relieves migraines") and the competitive advantage ("fastest").

This also points out that communicating the general market benefit is often unnecessary because the end user already gets it. If I have migraines, I already understand my pain and I understand the benefits of pain relievers. You don't have to tell me migraines are "painful," just get to the point!

As another example, this time from Smart Bear, we claim that one way Code Collaborator saves time with code review is that we show chat next to code, and the chat sticks with the code even when you upload fixes (where the line numbers shift around). On one hand, we're describing a general feature (chat in context with code) shared by all 3 of our major competitors, but at the same time we point out features that only we have (i.e. two competitors show chat in a separate window, not with the code, and no competitor is good enough to keep chat in the right place even after files are updated).

If you want to stick out from the crowd, explain why you're the best medicine, not why I need to take medicine.

P.S. Exception: If you're pioneering a new market space, this idea doesn't apply. In that case you need to explain and defend your very existence; in fact this was the case at Smart Bear for the first 5 years.

Limiting Options

2008-04-20T15:19:00.000-05:00

The 1990's was the golden age of computer AI's for the board game Othello. OK, it was pretty much the only age.

Programmers love the thought of computers beating humans at "intellectual games." For me it's the "mad inventor" idea of creating something more intelligent than myself (whatever that means).

At the time, Checkers had been solved and even Chess was close. It was Othello's turn to fall.

What's interesting is how the winning strategy worked.

The typical computer board game strategy is to look many moves ahead and rate each resulting board position. Then you pick the next move that maximizes the ultimate board position you can achieve. The trick is in rating the "goodness" of a particular board position.

In Othello you win by having more tiles of your color than your opponent once there are no more possible moves. Therefore, typical metrics for Othello included things like "How many tiles of my own color do I have" (more is better), and "Tiles of my color at the edge of the board are more valuable than in the middle" (the edge is a better strategic position).

What's neat is that the winning strategy used a completely different "goodness" metric. Specifically the metric was: How many valid moves does my opponent have? Fewer is better.

The flip was that it's not primarily about how many tiles you have or even the positions of your pieces. Instead it's about limiting how many choices your opponent has. Limiting choice is more important than what the choices are.

This principle is common in defensive theories of sports. The defense can never cover all contingencies so instead it forces the offense into higher-risk, lower-percentage moves. In basketball you can't simultaneously cover the long shot and the charge, so you elect to give up the low-percentage three-point shot. In football you can't cover both in-routes and out-routes, so you force a throw into as much traffic as possible.

In business your competitors always have options. How can you limit their choices to things that are low-percentage or expensive? Make them have to spend more money, get more lucky, or be more creative.

An example is honoring a competitor's coupons. This eliminates the coupon as a way for your competitor to "beat" you; coupons are no longer a "choice" to develop a competitive edge.

You can think of patents as a way of limiting choice. If no one else can use your method, they'll have to think of another way. That means research time and money, and maybe it won't be as good or it will be more expensive to manufacture or support. (That is, if you believe in patents...)

We've done a few things at Smart Bear to limit options. For example, we're so strongly established as "the experts in code review," it would take an expensive, time-consuming effort for someone else to claim par, much less surpass what we've done. We literally wrote the book, we did the largest-ever study on code review, we have years of history, we have the most popular tool. It's possible, but very hard, for someone else to compete on that particular basis.

This matters because in my opinion, being "the expert" is the best qualifier for our particular market. Our customers would be less interested in "lowest cost" or "simplest installation" (even though our installation is simple). If my opinion is true, I've removed the single best choice from competition, and they'll have to find a less desirable, lower-percentage path.

Agile marketing interview at GeekAustin.org

2008-04-14T12:05:00.003-05:00

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.

The Anti-Bullet Test

2008-04-06T09:50:00.001-05:00

I'm sick of generic feature/benefit bullet points. They're just too easy to make fun of. Here's a sampling from a website that will remain nameless to protect the guilty:

Easy to use
Robust features
Innovative systems

Really, it's easy to use? As opposed to what, difficult and temperamental? Robust, huh? Great, because it looks tenuously held together, the slightest breeze threatening to crumble its delicate construction, so it's good to know that, actually, it's robust. Oh I'm sorry, its features are robust, whatever that means.

If you want to not stand out from the crowd, use generic statements. The ones everyone claim. Would anyone claim to be non-innovative?

So here's Jason's Anti-Bullet Test: For each feature/benefit bullet point, construct its negative and see if that statement is ridiculous. If it is, it means the bullet is obvious, or at least unoriginal. It's not strong, it isn't adding excitement, it's not differentiating you from your competition.

Let's apply the test. The negative of "Easy to use" is "Difficult to use." That would be a pretty funny statement! No one would ever claim that, so throw it out.

The negative of "Enables communication" is "Blocks communication." Crazy; no one would admit their tool does that.

The negative of "Stores files as big as 100 gigabytes" is "Cannot handle very large files." Not ridiculous, in fact this is sadly true of most computer systems of any kind. It passes the test.

Here's a good one from our own product: "Integrates with seven version control tools." Negative: "Not integrated with seven version control tools." Not particularly funny; in fact this statement is true of all our competitors. So this statement differentiates ourselves in a specific way.

If you're using generic bullets now, you'll find that replacing them isn't easy! You have to really think about what's strongest about your product, about how specifically it beats the alternatives, and how make it pithy. This is a useful exercise in itself.

One exception to the Anti-Bullet Test: You can use a generic if it's your single biggest differentiator, and if you're willing to put lots of energy behind it.

A good example here is "Fastest." The negative is funny ("Slow operation means lots of time staring into stagnant progress bars"). But if you make it your highest priority, it can work. Make your bi-line "The fastest ____." Prove it with benchmarks. Explain how speed is not only about saving operator time (the obvious benefit) but how it enables entirely new features. For example, perhaps operation X is typically so slow that people can't take advantage of it. But since your system can complete operation X in two seconds, suddenly it becomes a feature. Even if a competitor technically has the feature, you make it practical.

All this is just another way of saying: Be specific, be fully committed, and tell the truth.

Identity Crisis

2008-03-30T10:11:00.004-05:00

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.

Caricatures

2008-03-22T14:02:00.003-05:00

Political caricatures are less about exaggerating features and more about telling a story.

A caricature emphasizes unique features. Every candidate has two eyes, a nose, and a mouth, but only one has big ol' ears. A caricature also has a point of view -- is the candidate cool? Old? War-hungry? Defensive?

All in a picture. No words.

If your product had a caricature, what would it look like? What are the unique features you would emphasize?

It's useful to think this way because you can't throw 800 typical marketing words into one picture. "Easy to use." "Scalable." "Fast." "Enterprise-class." "Flexible." "Customizable." "Reporting."

Everyone claims these things. Snore. What if you had to pick just one? Or better yet, find something else that few others can claim. Something you can assert that your competition couldn't even try to say.

And putting it into a picture without words is useful too. Communicate a powerful, unique message in 3 seconds. Something that might otherwise take a paragraph. A paragraph your potential customer might not take the time to read.

An example from Smart Bear is our side-by-side screenshot. If you're a developer, and you reached our web page because you're looking for help with code review, this image is all you need to know. The "content difference" concept is obvious; the fact that it's in a web browser implies you can do this from anywhere, at any time; the piece on the left is obviously a chat area, which implies you can talk; the blue borders around code-line and chat implies you can talk about code.

You can use the same trick for identifying how you treat customers. Now you can't get away with saying trite, meaningless drivel like "we value our customers" or "we exist to serve our customers."

If you really exist to serve your customers, the picture might be of an average-Joe being served wine by a suit-wearing executive. I like that image! But is it accurate? If so, put it up on your "Our Customers" page and show you mean it. But if you the thought of that image makes you laugh, if that's not truly how you picture your relationship, then rethink your values.

P.S. The image above and comes from a fascinating entry in the NY Times Blog.

Discount gambit

2008-03-21T22:59:00.001-05:00

Which of these pricing strategies is more persuasive?

If you buy now, I'll get you a discount.
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

2008-03-21T21:34:00.001-05:00

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!

2008-03-12T17:59:00.002-05:00

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:

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