Blog has moved!

I've officially moved my blog to this address:

http://blog.asmartbear.com

Actually it's been there for about a year, but recently I switched blogging platforms from Blogger to Squarespaces, so if you're seeing this message you're being left behind!

If you're subscribed to the emails or the RSS feed, you don't have to do anything.

Thanks!

Agile Marketing: The Movie

I can't believe I started by saying "OK, people."  Talk about your crappy opener.  But with six minutes and thirty-eight seconds remaining, I had to press on.  And plus Alexis had just brought down the house.

Let me back up.  In April I had inadvertently coined the term "Agile Marketing" in an interview.  It means applying certain principles of agile development to the world of marketing and advertising, and it's a nice metaphor for how we approach marketing at Smart Bear and something I'll be writing about more in future.

A few months later I was selected to do a pecha kucha at the Business of Software conference (run by Joel Spolsky & Neil Davidson).  A "pecha kucha" is a rigidly-timed presentation with twenty slides, twenty seconds per slide.  It's a fun format that encourages brevity, sparse slides, and focus -- attributes you've wished upon many presentations.  So now you can see the fun: business and geekery in a single six-minute-forty-second package!

The day of the conference I learned I was presenting second, behind Alexis Ohanian, founder of Reddit.  And his presentation was really great.  Not great in the sense that I was inspired, or learned something, or came away with a new idea; it had none of that, it was satirical.  But it was hilarious.  This was a bad thing.

Bad?  Oh I forgot to tell you.  See, this was a competition.  The conference attendees would vote for their favorite pecha kucha presentation.  Now I know, life isn't a competition; my value as a person on planet Earth isn't established by whether people vote for some presentation at some conference.

Except that, yeah, it kinda is.

So before I started my talk I tried to reset the mood with an old improv comedy crowd warm-up routine where you get everyone all excited and clapping and then make a dramatic sweeping motion to silence the house immediately.  It's a weird effect because you don't utter a word or explain what you expect them to do beforehand; the weird part is that it works every time.

So here it is.  (And please forgive that "OK people."  Sheesh!)

P.S. If you like talking about the stuff in the video, run over to the Business of Software networking and forums website and get involved.  This isn't just another pile of threaded conversations; it's real software entrepreneurs talking shop.

P.P.S. If you're wondering about the panda peeking over the PIP at time index 2:40, here's your answer.  And poor Eric I referenced at 3:57 is Eric Sink.

P.P.P.S.  Alexis won.

The leading provider of meaningless marketing solutions

Why do so many marketing departments strive for ambiguity and meaninglessness?

Witness, for example, this gem of a company description.  As Dave Barry would say, I'm not making this up:

Omniture, Inc. is a leading provider of online business optimization software, enabling customers to manage and enhance online, offline and multi-channel business initiatives. 

Huh?  Turns out they do web analytics.  Oh.  They could have just said so and spent the rest of their words telling you how they're different from other web analytics companies.  

What's the purpose of this language?  Does the phrase "a leading provider of" mean anything to you?  When you read it, do you whisper under your breath:

Awesome, I found the leader!  They lead the other providers around like cattle.  Well, they are a leading provider, not the leading provider, but still, one of the leaders!  I'm impressed.

Nah.  At best you gloss over it -- an overused phrase, devoid of meaning.  At worst you lose interest and click the "Back" button.

Perhaps the worst offender is the word "Solution."  What is a "solution," and how does it differ from, say, a product?  The main menu of many web sites makes me choose between "Products" and "Solutions."  How oh how do I choose?

My favorite example is AT Systems.  Their proud motto:

Now that you know the company name and their motto, here comes the question: What do they do?  After you guess, have a laugh; go here for the answer.

So back to the question: Why do marketing departments churn out meaningless phrases?

Possible Reason #1: Fear.  Generic, widely-used phrases don't offend.  They avoid lawsuits; it's hard to sue over meaningless words.  This excuse might work at Big Company Inc, but in a startup you can't afford to be bland and wishy-washy.

Possible Reason #2: Laziness.  Saying "A leading provider of business solutions" is a lot easier than taking the time and effort to nail your message.  It's hard!  You have to know your customer, boil your company down to its essentials, and be succinct and evocative.  It's easier not to.

Possible Reason #3: Incompetence.  What if you don't actually know what sets your product apart?  What if you can't articulate the niche your company owns?  What if you can't describe your perfect customer?  Then you have to resort to generic phrases.

None of these excuses are valid for small companies.  If you can't articulate your product in a few, choice, specific, words, your potential customers won't get it either.  You have to do the work yourself because you don't have TV ads and 300 sales reps to pick up the slack.

I'll leave you with a tragic example of what not to do.  See if you can guess what this company does:

webMethods (Nasdaq: WEBM) provides business integration software to integrate, assemble and optimize available IT assets to drive business process productivity. webMethods delivers an innovative, enterprise-class business integration platform that incorporates proven integration technology with next generation capabilities into one interoperable set of tools that delivers a unique combination of efficiency, agility and control. webMethods combines industry leadership with a zealous commitment to customers to deliver tangible business value.

Take a scalpal to your marketing content.  Make every word count.

Five ways to listen to customers instead of goin' fishin'

Lots of small business bloggers tell you to listen to the customer and build accordingly. But some people take it too far.

I recently had an experience with just such a company. They had finished their product demo and I was wrapping with a few standard questions.

Me: What's on your roadmap?
CTO: We're going to listen to what you need.

Notice how it evades the question, like a politician. He might as well have said, "The future is whatever you think it should be." Perhaps he's trying to demonstrate receptiveness to feature requests, but it's a non-answer.

Follow-up questions failed to uncover a roadmap. Maybe because they don't have enough customers to know where to go? The next snippet provides more evidence for this theory:

Me: Do you have any questions for us?
CTO: Yes. What is your biggest business problem that you would like someone to solve?

Fishing for ideas? Are you asking me to define your next product for you?

This isn't "listening to customers," this is a rudderless ship. Having clear goals and confidence is compatible with customer-guided development. What you should be doing is active listening:

1. When a suggestion appears, notice and write it down. Restate it in your own words and repeat it back to ensure you understood correctly.


2. Dig into feature requests until you find the root pain point. This means back-and-forth communication so do this on the phone or in person, not email. Often there are ten ways to address a problem and you have other customers and a product architecture to consider.


3. Ask them to order their suggestions by importance. Often a list of twenty suggestions yields only two deal-breakers. No priority levels are allowed, just an ordering; otherwise you end up with seven "Priority 1" line items.


4. If you can't (or won't!) implement something, admit it. Explain why so the customer understands you're being pragmatic and forthright, not dismissive.


5. Collect feedback proactively. Most people won't send an email to support with a feature request; they've been conditioned by most companies that such things go unnoticed. One way we've started doing this recently (with much success) is through a Uservoice page.

Notice in all cases you're simultaneously engaging the customer and honing the suggestions. Engaging means the customer feels like you're genuinely listening and giving thoughtful consideration. Honing means you'll leave with concrete things to consider.

Even admitting something is impossible is constructive because then when you do accept a suggestion they know you mean to implement it. You're displaying honesty and setting up reasonable expectations. People know all twenty of their ideas can't be done; they'll appreciate honest rejection.

Companies that listen are both rare and beloved. Listen, don't fish.

If you have more ideas for active listening or dealing with feature requests, please leave a comment for others to enjoy!

Voting early: What if there were no election day?

In Texas we have early voting. For two weeks leading up to the election, you can vote by mail or in person. In Austin, where I live, you can vote in any of 26 locations, open twelve hours a day including Saturday and six hours on Sunday.

I went on a Tuesday morning.  It took me less than ten minutes to vote.

Of course now all you hear about is election day chaos with long lines, machines breaking down with no paper-based back-up, and voters on the west coast influenced by election returns from the east coast.

What would happen if there were no election day, just early voting?

1. Voters wouldn't be affected by state returns, time zone differences, and the news networks "calling the race for whomever" every ten minutes.
2. Lines would be shorter because polling locations are open for many days instead of one.  Shorter lines means more people actually vote.
3. The quasi-laws requiring employers to allow employees time off to vote could extend to the extended voting period, causing less disruption as people take off different days and times rather than all at once.
4. The time pressure to report results vanishes.  You have at least the two weeks to accumulate numbers, plus some pre-determined number of days after that.  Now you can recount close races and double-check numbers without the time pressure and scrutiny of Wolf Blitzer and the Fantastic 12.
5. Some swing states in this election aren't used to high voter turnout (Michigan, Colorado, Nevada, Pennsylvania) and are anticipating problems with insufficient number of voting booths, long lines, and not enough back-up ballots in case a machine fails.  With the voting spread out over more time, it's easier for each location to have enough back-up paper.  You could even extend the number of voting days if you needed to.

I suppose you lose the suspense and drama of voting day results reporting, but it seems like democracy would be better served.

What do you think?  Leave a comment.

Love the messenger

I'd had Korean food before, but as this was my first trip to Korea House I wanted something different, something authentic, maybe even adventurous. Friday lunch at Smart Bear is usually interesting.

PJ recommended the bibimbap, a bowl of rice covered in Korean namul with beef and an egg. Perfect, but when our waiter got around to Hannah -- herself Korean -- she ordered the dolsot bibimbap. Ooo, it's a sign! So when it was my turn I asked the waiter the obvious question: "What's the difference between bibimbap and dolsot bibimbap?"

His answer: "Dolsot bibimbap better."

That's it! Better. Well of course I ordered the dolsot, and it was fantastic. Turns out "dolsot" means "stone pot." The dish is served in a hot stone or ceramic pot hot enough to sizzle and cook anything that touches the sides. The rice gets crispy, the egg cooks, and the veggies and meat stay extra hot.

At this point, my long-time readers will expect me to make some point about how marketing messages need to be more specific than "it's better," how differentiation always trumps ambiguity, and how every phrase should be meaningful. But actually, his response was perfect.

It was perfect because it wasn't in an ad, wasn't in a datasheet, wasn't part of a 30-second elevator pitch mechanically regurgitated on a tradeshow floor. It was from an old Korean guy who works his ass off at Korea House, possibly seven days a week, probably related to the owner. He barely knows enough English to parse my question -- certainly not enough to articulate the answer -- but he did his best to push me to the right choice, the one that was $1 more and 2x better.

It's the messenger, not the message, that makes the experience wonderful.

So yes, on websites you do need to be specific because websites aren't relationships; they're attention-getters and information-distributers. But as soon as the human relationship begins -- whether by sales pitch or tech support or tradeshow booth -- the most important thing is to be genuine in your passion, knowledge, and desire to make your customers successful.

2000 feature requests: Our foray into Uservoice

Question: What do you do with two thousand feature requests sitting in an issue-tracking system?

Answer: Nothing.

We have so many requests because we make it clear that we want to hear from our customers.  And they talk to us... a lot!  It's great that so many people have submitted so many ideas, but we're drowning.

How do you prioritize 2000 items?  How do you know which ones were really important to the requestor and which were just a passing fancy?  How do you track which ones are related or are duplicates or have a common solution?  How do you have separate discussions internally and with customers to dig up the root problems?

You don't.

And anyway you only have time to implement a tiny fraction of the requests, so almost all the time you spend getting the list ship-shape is wasted on features you'll never implement.

You could ignore feature requests entirely on the theory that the important stuff is requested often enough that priority makes itself apparent.  This works if your product is extremely simple, and if you've decided it won't have many features.  If you can get away with such a product, by all means do!  But not all software can be simple.

Besides, I like the fact that we get feature requests.  Our customers tell us what to build -- it's a logical way to create a product people will pay for.  But thousands of feature requests areimpossible to manage; it's almost the same as having none.

Enter Uservoice.  What a great name; it says what it does, it's evocative, it's even empowering ("giving users a voice").  The concept is simple: Anyone can post feature requests and vote on their favorite ones.  Each request has a mini discussion forum.  The most popular requests rise to the top of the list.

Want to see it in action?  Visit our page: http://feedback.codecollab.com/

We're going to push the hell out of Uservoice.  For example, we're putting a "Suggest" button in the menubar of every screen in our software.  Every feature request sent to tech support will be redirected there, and we'll be going through our feature backlog redirecting folks to the new site.

The hope is that users will self-organize.  Popular features will have more discussion, not just amongst users (because who can agree on the best way to implement something?) but between our developers and our beloved users.  Now we can ask questions of everyone interested in a certain feature, hopefully getting to the heart of the real pain that our users are sharing.  We could never do that with a massive list of line-items in an issue tracker.

If this works, the same technique could be used for all sorts of things:

• We're setting up an private Uservoice site to track marketing ideas -- we have 50-100 ideas and we'd like to start internal discussions on which ones to try next.
• Have one Uservoice site for existing customers and a separate one for potential customers just trying it out.
• Let your customers give you feedback on your website.
  
• If you're a consultant, lawyer, speaker or other professional you could use it for anonymous feedback.
  
• Company "management" could demonstrate they care about doing a good job by opening a personal, anonymous site for feedback (like glassdoor, but private).

I'll keep you posted as we learn more about Uservoice's shortcomings and advantages.

If you have experience with Uservoice or any other self-organizing feedback system, or if you've contributed to our feedback site, please help us all by leaving a comment!

Is it OK to Sucks?

I first read that bizzare phrase -- is it OK to sucks? -- in a Slashdot article seven years ago. Companies like Lockheed Martin were suing people who registered LockheedMartinSucks.com and a big battle ensued over the line between free speech and trademark violation.

I had that phrase in mind when I suggested that the title on our full page advertisement should read:

Peer code review doesn't have to SUCK.

We were brainstorming.  There were other ideas.  I had to admit it might offend some readers.  I lost.  Fine.

We went to press and the ad did really well.  We scored in the top 95 percentile on various measures in an independent test.  We got a surge in folks trying our stuff and asking questions.  So no regrets... but still... "suck" is funny...

Six months later I got the SD West 2007 Conference Guide.  On the inside front cover was a letter from the conference organizer entitled, "A Conference that Doesn't Suck."  Hey!

Then I find David Platt is giving a talk called "Why Software Sucks."  The work "suck" appears three times in the course description.  In fact he even wrote a book with that title.

Nowadays it seems like every day I see a company with big-name customers who uses the word "suck" on their front page.

Turns out it is OK to sucks!

It's better than OK.  Small businesses have to get noticed with no money.  The least you can do is give yourself a notable phrase.  Or image:

Take a chance.  Risk offending.  If you don't offend some people, you're not saying anything worth hearing.  Being notable beats being forgotten.  For every person who is offended there's another who just fell in love.

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.

Labels Matter

A dour-faced executive glanced around the oak conference table, somehow able to look simultaneously down and into everyone's eyes in turn. He said: "The question is, where can we get more resources for Mike. Roger, can your group relinquish some resources for three months?" Roger frowned and pondered. I wondered what a "resource" was and how many Roger had.

It was a brief consulting engagement. Version 3.0 was behind schedule. I was privy to this product planning meeting but still naive about corporate lingo. At first I thought "resources" meant money or time but it didn't compute.

Finally I realized that "resource" meant "human." Or, in this case, "software developer." Oh.

The dehumanizing effect of labelling anyone as a "resource," a category which might also include electricity, water, natural gas, and hogheads (hogs head? hog's head? hog's heads?), is obvious enough. But more interesting is the effect it had in the meeting.

In Orwell's 1984, a tyrannical government has forced upon its citizens a language called Newspeak. Newspeak has no words for concepts like disagreement, revolution, or individualism. The theory was that people cannot engage in these thoughts if there are no words to express them.

So back to the executive and the oak conference table and "resource reassignment." Did using the generic word "resource" have an effect on the planning session?

Oh yes. In that meeting it was determined that two resources would be temporarily reassigned from Roger's group to Mike's, so Mike could complete his features on schedule. Is that sensible?

If you're talking about human beings, of course not. Two people were assigned to a project they knew nothing about. We've known forever that adding people to a late project only makes it later; the absurdity is multiplied by re-reassigning those people three months later, just when they might finally be up to speed.

But when you're talking about "resources," it makes sense. Resources are fungible. Money is a resource; it can be moved from one department to another with a click in a spreadsheet. The analogy to human beings is completely wrong, which leads to completely wrong decisions.

But the moral isn't "Don't label." In fact, we can do better than "Labels must be accurate." Maybe you can use labels to advantage.

What if you called your software developers "The Talent." Like Hollywood stars. The Talent are not interchangable. The Talent demand respect, but they are expected to produce. The Talent can be opinionated, judgemental, and tempermental, but it's worth placating them so long as they churn out great works that can be sold for millions of dollars.

Which label will help attract and retain the best developers?

Labels matter.

What are your pet peaves when it comes to labels? Do you have a story of mislabling leading to wrong decisions? Leave a comment!

Ideas for Swarm

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:

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


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


3. 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.
   
   
4. 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?").
   
   
5. 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.)
   
   
6. 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.
   
   
7. 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.
   
   
8. 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.
   
   
9. How does synchonization work?  Locks-held need to be part of the continuation.  But are there other subtle issues?
   
   
10. 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.
    
    
11. 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.
    
    
12. Fault tolerance. Probably don't have to have this at first, but need a thought-experiment-level concept of how to handle.
    
    
13. 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.
    
    
14. 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

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

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

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

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

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:

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


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


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

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

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

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?

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