And yet John and MG are totally right. You either see it or you don’t. This is egalitarian, relating to all facets of life, in every nuanced area of preference or priority. For whatever details a given person appreciates and values, far more people will be disinterested and be unlikely to even distinguish differences. How about those Android aficionados? They’ll point to the flexibility afforded by true multitasking, freedom to install unapproved apps, etc. They shake their heads at silly iPhone lovers, hold their phones up high and take pride in these qualities. To them, these are the finer points. This is the “polish.” The rest of us just don’t see it.

For many of us who make, use, or write about software for a living, polish is all about removing from the software as many jarring behaviors as possible. Sweating the small stuff. It’s exactly the details like the persistently stuttering scrolling that MG points out that continue to make Android products appear less polished to us. It’s seriously unnerving. It’s a big freaking deal to us, while other people just don’t see it.

It doesn’t have to relate to expense, and isn’t restricted to a premium class of product. It’s also, of course, not restricted to vision. I can imagine some of my wine-loving friends holding up a $15 bottle of something precious they’d discovered, while expressing disdain for a $200 bottle of swill that somebody else just adores. Nor does it need to be something “high class.” I’m sure a number of hard-working farmworkers could explain to me in agonizing detail why I picked the absolute worst rake and shovel for my garden.

If you’ve got a taste for something, a nose for something, an eye for something, an ear for something, a feel for something, and you find a product that soothes that sense, then you have a special gift: the ability to cast judgement on inferior efforts. Other folks? They’ll either sense it too, or they won’t.

Judging by the massive response on Twitter in support of her opinion, I think that most people tend to agree. However, I think that the vagueness of her description of the incident leaves much to the imagination, and is causing people to leap to condemnation of the talk, the conference, and the industry. I am not saying the condemnation is unwarranted, but my feelings about this particular event are complicated, and I think yours might be too, if you knew more of the details.

The talk in question was titled The Ten Dirty Words and How To Use Them. The talk was given by my friend Andy Lee, and his synopsis from the conference session descriptions reads:

In 2003, I came up with “The Top Ten Cocoa Words That Sound Dirty But Aren’t.” By finding APIs via this arbitrary way, we talk a random stroll through Cocoa, which can stimulate curiosity and lead to new discoveries and new questions. What would you guess NSInsertionPosition is for? (I incorrectly guessed text editing.) It can also be worthwhile reviewing familiar ground. We all autorelease — some of us every day — but it may still be possible to learn a thing or two about it. I will talk about the proper use of each word in the list.

To give you a more specific idea of the offensiveness of the API method names that Andy discussed, take a look at his blog post listing the API methods under discussion. [Update: MacTech has just posted slides from the talk.]

The genius of this talk is it takes a running gag in the Cocoa community, that occasional API names here and there were unfortunately named, and runs with that gag as a scaffolding for exploring the specific APIs in more detail. As for the sexual jokes, I think they basically write themselves in the individual minds of the audience. As anybody who has sat through an all-too-dry conference talk about the specific technical blah, blah, blah of any subject can attest, it is generally a good idea to inject some humor into a talk’s structure.

So was the humor in this case too much, or too vulgar? I’m sure that Brittany was not the only person in the room who was offended by the talk. On the other hand, as the one “comic relief” talk in a 3 day schedule that contained more than its fair share of professionalism, I think it’s probably fair to say that some members of the audience were relieved to have a chance to laugh about something.

Injecting humor into any talk is dangerous. Especially with a diverse crowd, you are liable to offend somebody. Jokes of a sexual nature are even more dangerous. Even if the joke is not sexist, per se, there is a strong possibility that members of the audience will take offense because of sexual taboos in society. I also imagine the discussion of sex in a strongly gender-imbalanced setting will make members of the minority gender more uncomfortable than the rest of the room.

But neglecting to inject humor is also dangerous. The Mac and iOS communities have a strong tradition of humor in our conferences. Many of us feel annoyed and cheated by a conference if there isn’t a bit of liveliness. So, it goes both ways. It’s important to process this incident carefully to understand how it went wrong. Was the problem that there was a session with a noticeably lower level of “seriousness” than the other sessions? Was it that the session’s jokes were of a sexual nature? Or was it that the sexual nature of the talk’s jokes were not made clear enough to the audience before it took place?

I think what is happening on the web now is many people are seizing onto the angle of Brittany’s complaint that most resonates with their own frustrations about the conduct of our community. This is a valuable reaction and a good opening for further exploration. But what isn’t useful is the large number of people who are condemning the conference and the speaker without significant information about the context of what happened. I hope that I have at least helped to clarify that to some extent. If you still feel that blanket condemnation is the appropriate response, then I’m happier with your opinion now that you’ve read mine.

I just don’t feel comfortable paying for an iPad or web publication, no matter how good it is, and then having ads shoved down my throat. It makes me feel ripped off: what did I pay for?

His article touched a nerve with some of my friends and colleagues who are tied into the publishing industry, and who are aware of how important ads are to the revenue models of many magazines.

I think that I get, and agree with, the gist of Marco’s complaint. For better or worse, paying $4.99 for a digital copy of a magazine feels like a premium price. When you pay a premium price for content, it just feels wrong to many of us to have ads heaped on top.

Jason Snell, the Editorial Directory of Macworld, reacted to Marco’s post by suggesting that a magazine’s delivery medium shouldn’t affect whether or not ads are justified:

@marcoarment Wait, so an iPad version of a magazine shouldn’t have ads, but it’s okay in a printed magazine?

Jason goes on to suggest that publications have many costs, and typically the purchase price only pays for a fraction of those. Jason also links to a blog post from Craig Grannell, who also hammers the idea that publications need ads to cover costs, and closes with a quippish reply to Marco’s “what did I pay for?” question:

How about the content, and the wages of the people who write the content, and who design the app?

This epitomizes what I think is an overreaction by many folks to Marco’s post. People are zeroing in on the objection to ads, and inferring that Marco doesn’t believe magazines should be reasonably compensated for the content they provide. Marco never suggests this. In fact, he’s the one who ponied up $5 for a copy of content that he values. The exact price, and whether it supports the specific business model of the company he is patronizing, is almost beside the point. To him, it just feels wrong.

In response to the criticism, Marco seems willing to acknowledge that his feelings about the ads are trumped by the realities of the industry:

Tons of feedback from magazine/news people telling me that my feelings are wrong and that I simply need to accept that ads are necessary.

Peter Cohen, a journalist with years of experience writing for publications such as The Loop and Macworld, minces no words in his response:

@marcoarment It’s not your feelings, Marco. It’s your understanding of the economics of content production.

This is all well and good, informing Marco how wrong he is for feeling that $4.99/issue is a price that should justify an ad-free reading experience, but nobody seems to be willing to go deeper than vaguely condescending dismissal. All the accusations of contempt and ignorance are a little unsatisfying without specific analysis of Marco’s allegedly mistaken assumptions.

Obviously a magazine costs more than $0/issue to put out, and obviously it costs less than, say, $500/issue to put. Marco’s expectation to read a digital copy of a magazine without ads seems well-warranted if the cost of the purchase compensates the magazine with enough money to pay all of their staff, all their service providers, and some money left over for, if they’re lucky, pure profit.

If Marco had paid $500 for that issue of the New Yorker, I think few would challenge his expectation that such a price warrants an ad-free experience. But he paid $4.99, which happens to be the same price as a newsstand copy of the magazine. When you compare $4.99 to the $1.49/issue that The New Yorker charges its loyal subscribers for paper copies, printed on glossy paper and mailed to their homes, it already feels like a huge premium. Presumably the publishers are not losing money at $1.49/issue (with ads), or they’d cease selling subscriptions. [Update: it's been pointed out that they may well lose money on subscriptions if they know they can capitalize on secondary sales of books, etc., to their customer base]

We don’t know how much The New Yorker pays for bandwidth, or what percentage of their overall expenses the cover price accounts for. We don’t know if there are partnership fees for the digital version, or whether it needs to pay back a major infrastructure investment. We don’t know the specifics. We just know that Marco paid $3.50 more than a subscriber pays for the same issue, that it didn’t have to be printed, that it didn’t have to be mailed, and that it’s offered for sale in a venue where practically no other editorial content is sold at a premium price.

Is there something wrong with paying $5 for a digital copy of a magazine only to be subjected to ads? I don’t know. It may be necessary. It may be fair. But it felt wrong to Marco, and it feels wrong to me. That’s the publishing industry’s problem to figure out, and ours to complain about until convinced, by reasoning and without blanket condescension, to think otherwise.

When I first saw the Lion version of iCal, my eyes were drawn to the obnoxious bits of paper that cling to the top of the window, artificially and pointlessly leaving the debris that you might find on a real-life calendar with removable paper sheets:

As Cathy Shive pointed out in her NSConference talk on user interface metaphors, the presence of junk like this in an application is at best useless, at worst distracting and detrimental to the usability of the application. I remember her saying in her talk, before Lion’s iCal had even been presented in a private developer beta, that little things like paper scraps in an application are particularly annoying because she always wants to try to pick them off just as she would with a physical object.

Lion has given me the opportunity to empathize deeply with that concern. I hate those cruddy paper bits, and I can’t pick them off! Or can’t I?

To clean up your copy of iCal on Lion:

1. Select the iCal application in the Finder and press cmd-D to duplicate (make a backup, for safe keeping).
2. Control click the application icon and select “Show Package Contents.”
3. Navigate to Contents/Resources/
4. Select “CanvasTopTile.png” and open it up in Acorn or another, less attractive image editor. Or download my edited version and replace the original file.
5. Select the paper bits and “clean them up” by deleting them.
6. Reopen iCal, and bask in the glow of your clean white calendar:

Granted, this only fixes the paper bits. You’re still stuck with that horrendous tan leather toolbar. But at least that doesn’t beg to be picked at. It’s worth noting that the tan leather can also be tweaked by editing a variety of other image resources in the bundle. It’s trickier because many of the graphical components of the toolbar are designed to blend with the leather background, so you’ll end up having to change quite a few of the images.

I’m reminded of another great observation Cathy made in her talk: when you make very stylistic choices like this for a user interface, you dramatically increase the variety of reasons that the customer can be repulsed by the design. What if I don’t like leather? What if I don’t like tan leather? What if I prefer a running stitch to an outline stitch? You can argue that matte grays and subdued color gradients may invite the same controversy, but there’s a reason they are so common in user interfaces: because they’re far less likely to distract from the form and function of the application itself.

Addendum: Updating the iCal code signature. Thanks to rentzsch and daagaak on Twitter for pointing out that editing the resource will break the “code signature” on the application, put there by Apple to assure users that the application 1. Was developed by Apple, and 2. Has not been modified by anybody but Apple. You can re-sign the application after tweaking it, to put it back into a  ”signed” state, albeit not by Apple. Hopefully this will prevent it from prompting you all the time about approving connections to services like MobileMe. From the Terminal:

 codesign -f -s - /Applications/iCal.app

This reveals how little things like tweaking an application’s resources have wider-reaching consequences than they used to. I’m pretty sure you won’t miss any functionality in iCal by using a self-signed copy of the app vs. an Apple-signed version. But I could be wrong!

Let me break the announcements today into three policy change assertions, and how I react to them.

1. Access to Twitter direct messages will require a new level of user-granted permission. This is a great thing! I recently tweeted that exactly something like this was necessary, because I’ve grown tired of giving every damn service that I wish to connect to Twitter, access to all my confidential direct messages. The new permission allows developers of client apps to state their desired permissions, and those permissions will be listed prominently on your list of approved applications.

   Verdict: Kudos, Twitter.

2. Developers of Twitter clients will be required to use OAuth in order to gain this new permission. In laymen terms, this means client apps can’t log you in with just your username and password. You will need to be redirected to the web. This requirement is ostensibly because Twitter wants to increase the likelihood that end-users will be made aware of exactly which permissions a client application is requesting. Without this requirement, a native application could claim to seek read-only access, but behind the scenes be using your username and password, by way of Twitter’s xAuth solution, to request a higher level of permission than you intended to allow.

   I concede that this requirement is, on the face of it, an added protection for customers who are wary of providing Twitter credentials to an untrusted app. But here’s the catch with native software: you better trust it, because there is no shortage of ways in which it could screw you. It’s running with some degree of elevated permission on your own device. Twitter putting shackles on native app developers in the name of security is laughable. For example, it would be easy for an untrustworthy native app to provide a custom, compromised browser view that purports to drive a user through the Twitter OAuth permission flow with a given permission, but is actually requesting a different level of permission in a second, undisplayed web flow.

   This is not to say that we shouldn’t bother reining in native software that may be flawed or whose permission we may want to revoke. This is what is so clever about the xAuth workflow, the compromise that allows native apps to authenticate as if by way of an OAuth flow, but using a user’s username and password to facilitate the process. If an end-user or Twitter itself loses confidence in an xAuth based application, they can still revoke access to the application in the same way they would for any other OAuth managed client.

   Verdict: Nice try, but if you don’t trust your native software, Twitter can’t do much to keep you from getting screwed.

3. These requirements apply unilaterally to all native clients. Except Twitter’s. I grant you, it makes sense for a company to exempt itself from security restrictions that are imposed to prevent “bad guys” from taking control of a user’s credentials and doing damage to the user or to Twitter itself. But this story is complicated by the fact that Twitter entered a competitive market of native clients of its own system, where for years it was not a player, and then proceeded to adopt increasingly developer-hostile attitudes. In particular towards developers of software that aims to fill that coveted role of a “general purpose read/write Twitter client.”

   Is it illegal to do what Twitter has done? Absolutely not, nor should it be. But in my opinion these 3rd party developers were a valuable asset that was pivotal in building passion for Twitter in the earliest years of its existence. Many of the features that we take for granted in Twitter itself were prototyped in 3rd party native applications. Hell, even Twitter’s own native Mac app was itself a 3rd party application (Tweetie) until not too long ago.

   Twitter’s attitude towards these developers seems to be: thanks for all the help, but we’re done with you. The fact that Twitter is willing to “whitelist” their own apps further suggests that this may not be a pure security play. Only legitimate developers of trustworthy apps would be interested in seeking an API key to connect to Twitter. If your aim is to write malevolent software that abuses Twitter or its users, you should be content to take an app like Twitter’s own Mac client, extract the portions that communicate “securely” with Twitter, and build your own app that only the savviest user will notice is actually posting to Twitter as “Twitter for Mac.”

   Twitter’s willingness to exempt any apps from the OAuth procedure is a concession that they don’t view xAuth authentication as inherently insecure. But they want to limit which API keys get the privilege of continuing to use it. So, expand that list of API keys. At the very least, add long-time supporters such as Iconfactory’s Twitterrific. Better? Provide some kind of approval process through which any qualified developer can seek first-class status. Best of all? Stick to what OAuth and xAuth are best for: providing the power to revoke access for bad actors after bad intentions are discovered. Forcing applications through OAuth is not going to prevent offensive, buggy, or intentionally malevolent code from being authorized by users, but it is going to degrade the user experience for all native clients except, oh, how about that? Twitter’s own.

   Verdict: Dick move, Twitter.

One of the most important questions any business deals with is how it will be funded. If you’re thinking of starting a business, you should probably decide how you want to be funded early on, so you can orient your business towards being successful in the context of that funding.

Broadly speaking, a business will either be “bootstrapped” or funded by outside investors.

The goal for a bootstrapped business is to come up with your initial funding, be it in the form of cash, free time, raw materials, or some combination, and parlay these resources into a service or product that generates revenue from customers. Once the revenue from customers pays for the founders’ initial investments and sustains the recurring expenses of the business, theoretically including your salary as a founder, the company is profitable and poised to grow. The huge benefit to bootstrapping your own business is that, once the company is profitable, you retain 100% control of the business’s strategy and resources.

Another method of starting a business is to seek outside investment in the form of angel funding or venture capital. You give up some clearly specified percentage of the company’s ownership in return for cash, guidance, and social connections. From here, the goals are basically the same: to become profitable, but at the end of the day you end up with a smaller stake in your own company than you would have if you bootstrapped it yourself.

I think there are good arguments for both approaches, but I am strongly disinclined to seek venture funding for my business. When friends ask for my opinion, I almost always strongly discourage them from seeking it as well. Why? Because venture capital doesn’t speak to our priorities, and is unlikely to build the kinds of companies we want to run.

I was listening to the always-inspiring This Week in Startups podcast when an interview with Tony Conrad led to a perfect synopsis of why venture capital is not right for me. Jason Calacanis and Tony Conrad were discussing the state of venture capital in the technology world, and observed that consumers are spending a ton of money online, but there is a “risk” that the money is being distributed among too many companies. In a nutshell, they said, the online business world was becoming more like “Main Street,” with too many small businesses, and not enough “Walmarts” to pay back the massive returns.

This, Tony Conrad said bluntly, was his “biggest fear.”

Venture capitalists would rather fund a single billion-dollar company than a thousand mom-and-pop million-dollar shops. I can’t say that I fault them for this, but it cuts to the core of where their priorities lie: they gamble on high stakes, massive returns, while shunning the concerns of any business that wants to maintain a mom-and-pop Main Street business ideology. Personally, I prefer the Main Street shopping aesthetic to Walmart, and I know which part of town I want my business in.

If you want to be Walmart, by all means seek venture funding: you’ll need lots of it to stand a chance at succeeding. If, on the other hand, you want to build a company guaranteed to preserve your values, fund it yourself and maintain control. You’ll own something to be truly proud of while helping to scare the crap out of venture capitalists.

I asked him if he agreed with how they made their money. He replied in the negative — he’d just done the design. I told him we didn’t take on any projects that we couldn’t ethically stand behind.

And here I’ll quote him: “Must be nice.”

And that’s when I decided not to hire him.

Almost 15 years ago I was working my ass off at Apple as a junior engineer in the System 7 software updates team. I was trying to make a reputation in my new career, but also doing my part to make sure we shipped on time. In a historical sense, most what we built is hard to get excited about these days, but we were doing the exact same thing that Apple does today: iterating to give our faithful customers a reason to stay faithful.

In a group that was primarily oriented around fixing bugs, my colleagues and I were especially susceptible to a problem that plagues many developers: once you’re on the tail of a bug it can be hard to stop hunting until the issue is resolved. Some days we worked short hours. A hard-won victory at 4PM might be grounds for calling it an early day. But other times, stumbling onto a glimmer of hope with an impossible bug that “had to be fixed by next week” was cause for camping out until the wee hours of the morning.

One of these marathon bug-hunting sessions had a coworker and myself working until 2 in the morning, bleary eyed, but desperate for a solution. Usually I would recommend rest and resumption when it comes to this point, but we felt sure we were on the verge, and this was an important, difficult bug. We had a breakthrough, and spent another couple hours verifying a fix, testing it, and checking in the code. We went home exhausted but jubilant.

I collapsed at 5AM and slept until 11, conscious that the bug-busting marathon was not over. My boss, my boss’s boss, and for all I know, his boss’s boss were all aware of what we had done. It was a significant win for the team, but there was plenty more to do.

When I got into work after noon, my colleague was already there. He was talking, in the common area of our floor, with a humorless, long-time employee who worked in an administrative role with our team.

“Where have you been?” she asked contemptuously. “We need to ask you about the blah blah blah.” I’ve forgotten the specifics.

“Sorry, I was here late last night and only got in a few minutes ago,” I said.

“Must be nice,” she answered tersely. Her words stung. I was young, trying to prove myself, and had just returned to the fray after helping with an important victory. She had left at 5PM the previous night and had a long, restful night’s sleep. Or at least, that’s what I assumed she did.

What irked me most about her “must be nice” comment was how profoundly void of empathy it seemed to me. I hated her for years because of this. In part because of her, I have since been extremely sensitive to these pithy, jealous expressions: they jump out like smarmy little diamonds. But when words like these occasionally get lobbed at me, I am not nearly as hurt as I once was. I tap into my own empathy reserves, imagine what a crappy life they me struggling with, and try to wish the best for them.

It’s not so nice to be a person who says must be nice.

Update: I originally cited the content of a customer’s email in this post, and although I didn’t reveal her identity, I don’t think this was appropriate or particularly constructive.

Mea culpa.

In the future I will never cite the contents of a customer’s private email, no matter how anonymously, unless they have expressly permitted me to do so.

I have edited the post to remove the contents of our correspondence with each other. I am leaving the post because I still think it expresses some interesting ideas.

Continuing the recent trend of posts about, essentially, “just doing it,” the purpose of this post is to underscore the wisdom of staying in touch with customers, while acknowledging that doing so brings its own challenges.

Since I established my own web store a few years ago, I have collected the emails of customers who buy my software and, for those who leave the pre-checked option selected, subscribe them to a company newsletter for infrequent announcements:

Infrequently is the operative word here. In more than three years I’ve neglected to send even one email to these folks. This is a problem, because permitting me to contact them set up the expectation that I would. When major releases such as MarsEdit 3 have come out, some people don’t find out until months later, and tend to be annoyed that they haven’t heard about it directly from me.

Yesterday, I finally got around to setting up a mailing list with Campaign Monitor, drafting a simple plain-text letter, and pressing the send button. I finally broke the ice.

For those of you who are not on the mailing list, here’s what I said:

News From Red Sweater Software

Hello from Red Sweater! This is Daniel Jalkut, its founder and, for now, its only employee.

When you purchased one of my products, you agreed to receive infrequent email updates that keep you up to do date with my latest products. Since that time you have received approximately zero emails! I sort of dropped the ball on direct communication, but I’m working to rectify that now.

Messages will still be infrequent and hopefully pertinent, but if you are no longer interested in receiving updates about Red Sweater, just visit this link to unsubscribe:

(unsubscribe link)

On to the news: what’s happening at Red Sweater?

1. MarsEdit 3 Released

Earlier this year I released a major update to MarsEdit, our desktop blog editing application. MarsEdit now sports a rich text “WYSIWYG” editor, support for WordPress pages, and a media browser that integrates with iPhoto, Aperture, and Lightroom. Read more about MarsEdit 3 on the web:

http://www.red-sweater.com/marsedit/new3.html

If you don’t already own MarsEdit 3 you can purchase it for $39.95, or update from a previous version for $14.95:

https://www.red-sweater.com/store/

2. iPhone and iPad Releases?

People often ask about my plans to release applications for the iPhone, iPad and iPod touch. It’s easy enough to convey my intentions, but a bit harder to make specific promises. I am very excited about building iPhone and iPad versions of my apps, especially MarsEdit and Black Ink. I have made significant progress on these apps but there is still fine-tuning that needs to be done before I’ll be prepared to release them publicly.

3. The Mac App Store

You may have heard the news that Apple is planning to launch a Mac version of the App Store, which will give Mac users the ability to easily browse, purchase, and install applications in a similar manner to the way it works for iPhones and iPads. I’m hoping to get most or all of my apps into the catalog so I can reach an even wider audience of users. The good news for you, my existing customers? More customers will hopefully lead to more revenue, which means more resources and impetus to continue adding great features to the applications you already love.

4. Keeping In Touch

As I said earlier, I am resolving to do a better job keeping in touch. Next time a major update like MarsEdit 3 is released, you’ll hear about it before 6 months have passed! But if you want to proactively stay tuned in on an even finer level, there are some resources available to help you monitor our progress:

Email support. You can contact Red Sweater with whatever’s on your mind, be it a bug report, feature request, or just to say hi.
Address: support@red-sweater.com

Red Sweater Blog. The official company blog is my platform for providing a combination of company news and business-related thoughts and analysis.
Link: http://www.red-sweater.com/blog

Twitter accounts. For short, conversational style updates I maintain a personal account, a company account, and a special account just for MarsEdit:
Link: http://twitter.com/danielpunkass
Link: http://twitter.com/redsweater
Link: http://twitter.com/marsedit

5. Thank You

I want to close by thanking you for your business. I have been working on Red Sweater for over 10 years now, and in the past few years it has reached a level of success that supports myself, my wife, and my son. This is so unfathomable to me that I can only assume the sky is the limit! Let’s keep working together: your feedback and support combined with my desire to build great products should lead to many more years of successful results.

Daniel Jalkut
Founder, Red Sweater Software

To unsubscribe from this email list, just visit this link:

(unsubscribe link)

Delivery Confirmation

Campaign Monitor made the mass delivery painless for me. Thanks to their sophisticated tools, I know a day later that the vast majority of recipients received the letter, and only a small percentage have unsubscribed. Out of the thousands (wow!) of messages that were sent:

97.1% appear to be delivered
2.9% bounced
1.48% unsubscribed after receiving
1 reported it as spam (1 person, not percent – can’t win them all!)

This kind of feedback is great, but nothing compared to the direct responses I got from customers. The semi-personal tone of my letter inspired customers to respond in kind with heartfelt support and encouragement.

I received dozens of responses, ranging from the brief, enthusiastic “Word!” to longer, philosophical letters about small business, following one’s dreams, and the meaning of work in life.

Then, early this morning, I received this:

[EDITED: In retrospect, I do not believe it was appropriate for me to share the content of a customer's email here, even if information about her identity was removed.]

An upset or merely irritated customer always calls for a cautious response. The last thing I want is to escalate the situation. But this response is particular challenging, due to the number of provocative facets:

1. The customer is not pleased by the email I sent.
2. The customer is using a sarcastic, admonishing tone.
3. The customer projects a lack of respect by omitting proper punctuation and sentence structure.
4. The customer’s core criticisms are vague and subjective, making it hard for me to evaluate whether an apology or correction is called for.

These facets sort of multiply with each other and make it difficult not to respond defensively. My first reaction is to shout something into my email client like “What the hell?! Most people like a little humanity in a company, and furthermore, I did enumerate benefits where appropriate, and the content of this letter addresses the most common questions I have received over the past few months. And … and … who pissed in your Wheaties, anyway?”

Instead I take a deep breath, vent a little to my friends on IRC, and respond:

[EDITED: As with the content of the email from the customer, I don't believe it is appropriate for me to include the content of my response.]

I then proceeded to vent on Twitter about the response. I wasn’t particularly looking for comfort, but was glad to receive supportive responses from people who agreed there was cause to feel irritated by the customer’s tone. A sample of the dozens of reactions:

“That’s the kind of thing, when said in person, earns someone a kick in the teeth.” — @dssstrkl

“That guy is a jerk. Keep your personality in your work. if he doesn’t like it, let him use products from huge faceless corps” — @scottaw

“Personally, I couldn’t live with myself without adding a note about their tone. Why encourage an asshole.” — @mrgan

“Screw that guy. He’s just jealous that your Indie endeavors are successful enough to support you and your family. Good on ya!” — @fonix

“He presumes to speak for all your customers, co-opting “us.” He does not. Bravo on your measured and thoughtful response.” — @artgillespie

“That guy replied as if you were trying to sell him something. Your letter was more like a ‘state of the union’ communication.” — @morrick

Many of the responses refer to the customer as “him,” while none of them refer to “her.” In fact, this customer is either a woman, or a man with a very feminine name. Apropos of not much, but it’s interesting that we tend to assume somebody who is “being a jerk” is a man. I would have made the same assumption.

Do I feel a little disingenuous about responding to the customer politely and without indication of my annoyance, while essentially glorifying her message behind her back on Twitter and now here? Yes. This is not really my style, and I don’t think it’s very classy of me to share the private message of a customer, even if I am preserving her anonymity.

But, I think this experience is instructive both to customers and other small-business owners. And since I already vented on Twitter and essentially let the cat out of the bag, I thought I might as well go all the way.

Staying In Touch

What does it mean to stay in touch? It means building and preserving a relationship with customers. The stronger the relationship, the greater the empathy for the other’s circumstance. But as with other relationships, the increase in communication and contact leads to an increased risk of misunderstanding and offense.

My letter served a valuable purpose. It let my customers know that I’m thinking about them, that the checkbox they vaguely remember leaving selected wasn’t pointless. That I do have plans for the company and for the products they purchased, and that I am interested in turning a new leaf with regard to communicating directly with them.

The challenging customer and my reaction to her has also been helpful. It reminds me of the related importance of “staying in touch” with my own values and priorities. Over the course of Red Sweater’s growth, I have used a very rules-based approach to how I handle just about everything. Running my own business means biting my tongue and doing “the right thing” even when the instinct in my animal brain wants to do the opposite. This is true for coding habits, fiscal responsibility, and yes, customer support habits. A variety of informal rules help to keep me in line.

As I have gained confidence in my own decisions, I find myself more prepared to break these rules. I suppose that pragmatism slowly takes over. When I first started out, I informed my decisions by asking “what would a good business do?” Then I learned to admire other Mac software companies such as Bare Bones, Rogue Amoeba, Panic, and Omni, and asked myself “what would they do?” I still defer often to the wisdom of others, but sometimes I have the distinct pleasure of asking myself “What would I do?” and acting on it. Staying in touch with myself is as important as staying in touch with my customers.

Long time readers of this blog will note that I’ve had my dry periods as well. But watch closely: I’m blogging now about a thought I had just earlier this evening, while reading Twitter updates and responding to them. Colin Barrett complained that his perfectionism is limiting his blogging:

I plan to write more; I think my @secondconf talk on freelancing would work well as a series of posts. Just gotta get past my perfectionism.

I’m incredibly familiar with this line of thinking. In fact, it’s a variant of the indefinitely postponed software releases that I just wrote about. I read Colin’s tweet and, before I had even noticed that the neurons in my brain were firing, I had responded with a bit of encouragement:

@cbarrett The modern business model for solo writing is to blog your first draft and sell your final.

I’m referring to the fact that very few blogs are edited to the level of professionalism you might find in literary or scientific journals. On the contrary, some of the web’s most celebrated bloggers have let their essays loose in a semi-rambling form, only to piece them together later into a more refined, salable volume. Rands in Repose and Joel on Software spring to mind in the techie world, while writers such as Heather Armstrong and Julie Powell turned their respective parenting and cooking blogs into million-dollar enterprises.

The ever-so-thinly veiled message? Don’t worry so much. Just blog it. If you are among the lucky few who achieves perfection effortlessly, then by all means carry forth. The rest of us are lucky if we coerce a unit of coherent thinking out our brains and onto the web. Perfectionism? Your editor will help you achieve it after you’re famous.

LaMarche offers a fairly balanced presentation of the two sides, but in my opinion he gives too much credibility to the argument that nil’ing is a good idea. He essentially embraces the argument that nil’ing the variables in production code is wise, because it might mask crashing bugs that would obviously vex the user:

Generally speaking, this is only going to happen if you’ve got a bug elsewhere in your code, but let’s face it, you may very well. Anyone who codes on the assumption that all of their code is perfect is begging for a smackdown.

And speaking specifically about the approach I prefer, leaving the instance variable alone and not bothering to nil it out:

On the other hand, that approach is really, really bad in a shipping application because you really don’t want to crash on your users if you can avoid it.

I disagree with the assertion that avoiding crashes at all costs in shipping code is the right priority. The biggest disservice you can do to your users is to allow them to run code that has unpredictable behavior. The whole point of programming is to make computers accomplish tasks in predictable ways. Sure, we all make mistakes as programmers, but giving in to the chaos and putting up safety nets “just in case” is not the right approach, especially considering it has unwanted consequences.

Consider that by masking the crash from occurring in the wild, you may be putting off detection of and resolution of the underlying bug indefinitely. But if your application has a crash reporter, or if you take advantage of Apple’s iOS crash reports, you will learn quickly that there are issues needing to be resolved.

It is reasonable to take steps that mask mysterious crashes, but this should only be done after you know there are actually crashes to prevent. Masking the symptoms in a blanket manner is akin to cutting half the phone lines in the neighborhood and celebrating the reduced number of 911 calls.

It’s also worth noting that LaMarche’s defense of nil’ing out instance variables hinges on the presumption that messaging nil is safe. True, messaging nil will not cause a crash. But is that safe? Not if it changes the behavior of your code in unpredictable ways. Consider this incredibly contrived Cocoa-based nuclear arms controller:

if ([mDiplomat didReturnGestureOfPeace] == NO)
{
 	[[NuclearWarehouse nuclearMissile] launch];
}

By LaMarche’s reasoning, it’s a good idea to nil out the mDiplomat variable on release, so that it won’t crash when you message it. But in this case, messaging nil for a BOOL result causes a logical flaw in the program, with obviously dire consequences. If the instance variable were not set to nil, it would probably crash before the launch message could ever be sent.

We should aim to comprehend what our software actually does. Deliberately decreasing the symptoms of problematic code won’t lead us any closer to that understanding. Ship the best code you have to your customers, and if it crashes, try to fix the root cause of the crash as quickly as possible. Don’t get in the habit of writing “hope this fixes it” code, and by all means don’t adopt that philosophy as a boilerplate coding habit.