February 15, 2006

Q&A with Metamac

Shortly after the release of Yojimbo, Ben Schwan of Metamac conducted an email Q&A interview. He asked lots of questions, and since the answers were translated back into German, he graciously allowed me to post my original untranslated answers, along with his original questions (which he sent me in English, but one reasonably presumes that the original German was published with my answers translated to German. :-)) His questions, and my answers, are posted here unedited.

Q: Rich, for everyone who's living in a closet for the last 15 years, tell us a little bit about Bare Bones. When where you initially founded and what were the starting products? How big is Bare Bones today, employee-wise? What's your main products?
A: Bare Bones Software was founded in 1993 to publish and support BBEdit. Today, we have five products, including three Eddy award winners: BBEdit, the professional-strength HTML and text editor; Mailsmith, an extra-strength email client; and TextWrangler a high-performance text editor. Our expanding product line also includes Super Get Info, a file and folder info utility; and the brand-new Yojimbo, an effortless and reliable information organizer.
Bare Bones Software is not a huge company - our strength lies in having an exceptional crew of smart and talented people who produce and support our finely crafted products.
Q: What's different between Bare Bones and, say, smaller Mac shareware companies?
A: It's really not for me to speculate on the inner workings of other companies - I can really only speak for our company. It's our goal to develop and publish reliable, carefully architected products. That requires top-notch engineering talent, with customer service to match. Our products, sales, and customer support experience are recognized consistently as being a cut above. Essentially, our entire organization demonstrates the level of professionalism that our customers have every right to expect, and it's a team with which I'm very proud to be working.
Q: How much do you live from the good brand BBEdit is?
A: For a long time, Bare Bones Software was really only known for BBEdit, but in fact BBEdit is only one (though a very important) element of the big picture. Over time, however, we've been recognized for the big picture itself: consistently reliable products, and great customer service and tech support. With that, the Bare Bones Software name has become more widely recognized.
With the release of Yojimbo, we're reaching an entirely different set of customers than we have with our other products. So surely there will be a large number of people who only know us for Yojimbo. However, Yojimbo is built on the same basic principles as all of our other products, so our Yojimbo customers will get to experience what sets us apart.
Q: The Mac editor landscape has changed considerably in the last years. You got very good free apps like SubEthaEdit with interesting special features, you got shareware apps like TextMate who gained lots of traction with neat things like code folding. Can BBEdit still compete?
A: In the dozen years we've been doing this, I've seen the landscape "change considerably" many times, and all kinds of products come and go. We're still here. People buy BBEdit for its unparalleled engine strength and because it provides the features they need (or even just want to have at their fingertips). People buy BBEdit because they've heard about our first-class engineering and courteous and prompt professional tech support. People buy BBEdit because of the innovative features that we've introduced before anyone else (and we're not done yet!) — things like actual usable integration with Perforce, CVS, and Subversion; unparalleled automation via AppleScript and Automator; Text Factories for high-speed automated processing of multiple files; and blistering editing and transformation performance on even large files. None of that is ever going to change.
But don't feel bad about asking the question - people have asked how BBEdit's going to compete with page layout programs. Go figure. :-)
Q: Anyway, you're practically reduced the pricing of BBEdit to 99 Dollars with the availability of crossgrades from TextWrangler which is free now. Are there not many people out there any more who would pay 200 bucks for a professional editor?
A: We've always provided a crossgrade pricing path - not only from our free products like TextWrangler and (in its day) BBEdit Lite, but also from other commercial products such as Dreamweaver. Our crossgrade pricing has always been a generous "thank you" to those who have taken the time to use TextWrangler. It's gratifying that some people buy a BBEdit crossgrade as a "thank you" to us for their long time use of the freely available software, even when they didn't need, or didn't know they needed, the advanced features.
BBEdit is certainly worth US$199 - if you're a professional who uses it to make your living, that's a couple of billable hours, which is nothing compared the amount of money you make using it. If you're a student, the US$49 is a Saturday night's worth of pizza and beer. The fact is, we provide multiple price points for BBEdit because we know that our customers need to work within a variety of pricing constraints, and we're sensitive to that need.
Q: Was making TextWrangler free a good decision? Could you fend off competition with that move?
A: For a number of years, we have observed the crowding of the landscape with products which don't meet the standards for quality, strength and thoughtfulness to which we believe Mac users have every right. We de-priced TextWrangler because we see the need for a strong, feature-rich text editor at a low price. By making TextWrangler 2 available at no charge, we answered the call of Mac users who need a powerful, professionally executed product, and raised the bar for Mac text editors.
That said, it seems odd to characterize any action involving the generosity of a commercial software developer delivering free products as anything -but- "a good decision". There are certainly those who take advantage of the crossgrade pricing and buy a copy of BBEdit just to thank us for doing that — and "thank you!" is what we have to say to them. :-)
Q: What's next for BBEdit? Isn't a major overhaul in order?
A: As a matter of policy, we don't discuss work currently in progress, nor do we talk about future product plans or encourage "vaporware" announcements. When we have something ready, for real, we'll let you know.
Q: You didn't do any major new apps for a pretty long time. How come?
A: Considering that we've won three Eddy awards, for each of the previous three years running, you can imagine that we've been awfully busy. In addition, we've also just announced Yojimbo 1.0 which is clearly addressing the need for an effortless way to store, organize and master the onslaught of information we're all confronted with daily.
Q: How many hardcore MailSmith users are there left? Did you lose lots of people to Apple Mail?
A: As a privately held company we do not release sales data or other internal company information. However, the kind of person for whom serves is not really the kind of high volume email user that needs or appreciates the level of control achieved with Mailsmith.
Mailsmith is an extra-strength email client designed by and for Macintosh users, with unprecedented flexibility that allows users to customize its powerful editing, filtering, and searching capabilities to suit their particular needs. Novice users appreciate Mailsmith's simple interface for sending, receiving and managing email efficiently.
However, our core customer base for Mailsmith consists of "power users" who appreciate its unlimited search terms, unlimited filter terms and actions, and numerous other features for fine control of email processing. Mailsmith's extensive scripting support gives additional control.
Everyone benefits from seamless integration with SpamSieve, as well as the security benefits provided by the use of text-only email, and the availability of SSL encryption for server communications.
Q: Now you got Yojimbo. Tell us about it. What should people use it for?
A: "Define the universe. Provide three examples." :-) Yojimbo is here to help you master the onslaught of information, and store the "everything else" items that otherwise have no central place to go.
Until now, a lot of people used folders on their desktops for this purpose, but now there's something much better. Yojimbo makes it easy to store all kinds of information, and keep it close at hand — for example, I use it to keep little things like part numbers for my car; or some magic command-line incantation that I'm always forgetting; or web receipts for purchases made on line, and big things like entire user manuals - and everything in between. With .Mac syncing support, that information becomes available on all of my computers.
Q: Is Yojimbo with its rather low pricing and consumer appeal a change in Bare Bones' approach? Will there be more such apps?
A: Although Yojimbo is functionally unlike anything we've done — it's not a product for technical users that revolves around text processing, for example — it is every bit a classic Bare Bones Software product, conceived and developed in our best traditions. For example: Yojimbo was created to solve a problem that was of personal interest to us, and successfully projected on to the needs of our customers. Performance and reliability are designed in at the lowest levels. Every feature is carefully considered before it's implemented. Those are all classic attributes of Bare Bones Software products, and Yojimbo is no exception.
Q: Yojimbo isn't the first app in its space. How do you want to compete with Devonthink, StickyBrain and the like?
A: Well, information organization tools have been around since there's been information to organize. :-) We're no strangers to entering a space with existing product offerings, and our success derives from delivering a unique approach to solving the various problems that others have grappled with.
For example, getting information into Yojimbo is effortless — use a single key to open Quick Input Panel, drag something to the Drop Dock, or use the OS's PDF workflow features to "print" documents from any application right in to Yojimbo. This all happens without interrupting your work flow at all.
And that's just one example - more can be found in the .Mac syncing support that lets you have the same data available at all times - even on multiple computers. In general, though, Yojimbo was designed to stay at your fingertips and still be out of the way.
Q: Yojimbo looks pretty straight forward, programming-wise - you mostly use good Tiger technology. What was the hard thing designing the app?
A: Don't make the mistake of confusing a carefully crafted design with easy programming - it takes a lot of work to do it right. (For example, professional writers know that it takes a lot more effort to write shorter copy than is required to write longer copy.) In fact, an enormous amount of energy went into making sure that we delivered a product with a clean, focused, easy-to-use feature set and the sort of smooth and effortless behavior necessary to make it a success.
Q: Getting to another topic - the Intel switch. How was it for Bare Bones so far?
A: Considering that we shipped the first Universal build of BBEdit back in August, and a Universal version of TextWrangler back in November, and that Yojimbo is Universal, I'd say, uh, "pretty well". :-)
We had so many requests from transition engineers inside of Apple, as well as leading-edge Mac developers who needed a Universal version of BBEdit, that we went "all hands on deck" to help our fellow Mac developers and meet their needs as quickly as possible. And, of course, we shipped Yojimbo 1.0 as a Universal application.
We attribute the ease of our transition experience to good engineering discipline, and to following the "best practices" that Apple recommends to all Mac developers.
Q: Do you feel sort of betrayed that the new machines are there quicker? At least big software companies now got big problems. Are you fully moved out of CodeWarrior now?
A: Quite the opposite. This has been the smoothest major transition in the history of the Mac that we've ever seen (and we've seen a lot).
The switch to Intel was news in the middle of last year. Since the announcement, Apple has consistently gone "above and beyond the call of duty" to assist ADC members around the globe in their transition efforts — including enormous amounts of on-line resources, tools, and even one-on-one sessions.
At this point, any developer who hasn't started a transition effort or shipped a Universal application really has only themselves to blame.
As to CodeWarrior: we've been shipping products built with Xcode for a couple of years now, and all of our new product development is being done with Xcode as well - we haven't used CodeWarrior for production work for quite some time.
Q: The really good (and fast) Intel compilers only understand C+ + well. Do you thing we'll see a shift from Objective C at some point?
A: My crystal ball is taking the week off, but the empty whisky glass suggests to me that it's much more likely that the Intel compilers will be enhanced to support Objective-C.
Q: You're part of the Mac software scene for a long, long time. What has changed in the last few years? Is there a lot of positivity out there now?
A: These last few years have seen advances in Mac OS X that are truly a step ahead - the integration of metadata storage and extended attributes into the file system, fine-grained locking in the kernel for improved multi-threading performance, new APIs like Core Data and Sync Services, the continuing flow of improvements in the existing APIs. It's a great time to be a Mac developer.
Q: Would you recommend a talented developer to go "indie" professionally, like lots of people are doing now? Is it less than a gamble in the Mac market than on Windows?
A: Certainly, working for — or running — a company with multiple employees is a different experience from "going solo", but each has its upsides. It is not, however, my place to suggest what others should do with their careers - that's a decision that they should make for themselves.
It takes talent and discipline to design and implement quality software products, and anyone who does so is going to make their mark on the industry, regardless of whether they "go indie" or work for someone else.
Q: As a last question, how do you think the Apple year 2006 will turn out to be? Pretty good, right?
A: It's hard to interpret all of the innovations and product advancements coming out of Apple as anything but good news. I suspect that this year will be a little more about Macs and a little less about iPods than it has been over the past couple of years. We're also seeing more and more people switch to Mac OS X from Windows and Linux, which is an interesting dynamic. There are certainly challenges ahead, but I'm looking forward to '06 being a good year.
Q: Rich, thanks for your time.
A: With one more reminder to try Yojimbo :-), thanks for yours!

February 02, 2006

Of Pajamas and Ball Gowns

In a recent post, John Welch quotes me as saying:

Only the developer has to care. For the user, it's as immaterial as what color ball gown I was wearing when I wrote the code.

As much as I appreciate the attribution, I feel compelled to point out that I was actually misquoted. First of all, I only wear one ball gown. (It was a tragic fencing accident; don't ask.) More to the point, the words, as spoken to me by the estimable Jesse Feiler, were, as best as I can recall:

Whether an application was written using Carbon or Cocoa is as irrelevant as whether the programmer was wearing pajamas or a ball gown.

Apart from being more accurate (again, within the limits of my memory), it's also more believable, insofar as I could conceivably own both pajamas and a ball gown. (And it should go without saying that at the time Jesse made his memorable and piquant remark, I agreed strongly with his assessment, and I still do.)

November 21, 2005

Labor Saving Devices

In a recent posting on his blog, the amusingly self-styled "drunkenbatman" wrote about an interaction he was experiencing between a piece of application software and one of his haxies. In his wrap-up, he wrote:

I.E., the first email back was "Sorry, nothing I can do, APE affects Cocoa below my program.", but it's worth not giving up on, unless the company is an extreme example like BareBones[sic] (who throws up an alert saying they see APE is installed, and to uninstall it before calling support), which I always thought was exceedingly lame for just this reason. Basically, if this had been a BareBones product, they'd probably still have that bug in there. There's an implied arrogance behind that error message I can't get behind.

The issue of APE, haxies, and how they interact with application software is a divisive one.

On the one hand, there's Unsanity (the developers of APE) and their third-party developers, who are just trying to make a living by serving a market need. On the other hand, there are the application developers, many of whom have observed an uptick in tech-support volume (and its associated costs) as the result of interactions with haxies. And on the gripping hand, there are the customers, who want the capabilities offered by haxies (and thus enabled by the installation of APE), and who have every right to expect a stable and functional operating environment.

As written, drunkenbatman's statement is factually incorrect. I couldn't understand the origin of his remarks, and it did occur to me that they might be the result of an unstated bias. On reflection, I realized that if someone as generally well regarded as drunkenbatman can be so mistaken, then he, his readers, and many others would be well served by an explanation of the haxie issue from an application developer's point of view.

Whenever a report comes in of a problem that we've never seen before, it's vital to eliminate as many outside factors as possible, so that we know we're looking for the problem in the right place. If it comes down to being our bug, we'll fix it - plain and simple. But first we need to know that what we're chasing is what we think it is, so that we don't waste the customer's time. This is particularly important when the problem at hand is a crash or hang.

A few versions back, we added code to our products that detects whether the product crashed or was force quit the last time it was run. If we detect this condition, we then check for whether the APE bundle is loaded in our application space. If so, we advise the user accordingly, and recommend that they contact us if the problem persists after removing all third-party system additions and preference panels.

Here's the complete text of the alert:

You appear to be using one or more system additions or preference panels which employ “Application Enhancer”. Application Enhancer works by running its own code inside of BBEdit and other applications. This can lead to crashes, unpredictable application behavior, and other symptoms of incompatibility. If you continue to experience problems after removing all third-party system additions and preference panels, please contact <> for assistance.

We present this message for a very simple reason: we have unfortunately seen enough cases in which the presence of haxies causes the application to crash or otherwise malfunction that it's necessary to encourage customers to perform this important initial troubleshooting step.

This is not an effort to discourage these customers from contacting support. The quality of our technical support is a big factor in our success, and discouraging customers from writing to us would break the cycle of feedback and improvement that we rely on to make a better product.

Rather, if BBEdit wasn't quit cleanly and if APE is installed in the system, this important diagnostic step helps us help our customers simply because of the level at which haxies operate and the nature of the changes they make to the operating environment. Determining whether the haxie makes a difference before contacting support saves the user — and our support staff — time.

As Jason Harris, the author of ShapeShifter (one of the more popular haxies), wrote in commenting on drunkenbatman's remarks:

If I write a haxie, I'm changing the operating system environment into something that the original application developer did not expect. Therefore, any ill effects that result are my fault and my fault alone. It doesn't matter whether it's a bug in the original application's code, or whether it'd also show up using an Input Manager, or whatever. If adding my haxie makes it crash, it's my problem, period, end of story.

Thus, eliminating the variances in low-level system behavior that may be caused by aftermarket system extensions is an essential step in troubleshooting whatever it is that's causing the application to misbehave in the first place.

It's also important to note that, for this very reason, if you contact Tech Support with a previously unknown problem, the first thing we're going to ask you to do is to make sure that the problem still occurs after uninstalling all of your third-party system extensions.

Occasionally, a customer will write in with a known problem, or discover a new problem that we're subsequently able to reproduce on a reference system. In such a case, the presence of haxies is not an issue - it's our bug, and it'll get fixed. We've never used the presence of haxies as a shield against our own responsibility, nor will we ever do so.

So, there you have it. We don't have anything against Unsanity, their products, or their customers. We just want to make sure that our mutual customers have the information they need to troubleshoot their problem quickly and accurately, so they can get back to work.

October 26, 2005

Slowly going insane while waiting for a fix...

Over at Shirt Pocket, my friend and occasional co-conspirator Dave Nanian blogs about a bug in the OS that adversely affects his product and his customers' experience: Slowly going insane while waiting for a fix. In his post, he wrote something that really resonated with me:

This is really frustrating for our users, because things don’t work in a mysterious (and ungrammatical) way. And it’s frustrating for us, because it makes us look bad, incompetent and/or lazy. Honestly, we’re not.

We have had similar experiences, but I'll generalize: bugs and shortcomings in software beyond our control have the ability to profoundly and negatively affect our customers' experiences, and it's really frustrating for everyone — and for precisely the reasons Dave gives. (I'm likely to amplify on this in a future post.)

October 23, 2005

Is it OK to Eat Peanut Butter with a Spoon?

It's a quiet Sunday night after a fun and relaxing weekend. My desktop machine is working on a build, with the progress scrolling by in a BBEdit shell worksheet. Elsewhere in memory, my pre-release build of Mailsmith is chugging away on a torture test (rebuilding all 140,000 messages representing nearly 2GB of stored mail and database indices), and I'm conversing with a couple of friends in a couple of different iChat windows.

I've got a search results window in BBEdit showing 34 occurrences of a function call that needs to be replaced with something a little more modern. As I stare at this, wondering at the tedium of repeating the same process thirty-four times (write new strings, wire up a dialog/sheet, test, document, check in, lather, rinse, repeat) it occurs to me that my professional career began almost twenty years ago to the day (week, at least). I've been at this a long time, to be sure. (Aside: it's funny how, in this futuristic year of 2005, I make my living using the finest technology of the mid-1980s.)

So, time for a peanut butter break. It's definitely tempting to dip the spoon in and pull out a standard consumption unit of peanut butter, especially if the peanut butter in question is the grind-your-own stuff you can get at some grocery stores, and it's made from honey-roast peanuts. When it's that good, is it worth the effort to dig out the sliced bread and strawberry preserves? Or is it OK to grab the butter knife and lay the peanut butter thick on whatever bland Anglophone-branded crackers happen to be around? (That may in fact be the only option at the moment: bread is not in evidence.)

Then there's the floor-mopping problem. I'm not a huge fan of housework, but I'm also not a slob - I do manage to keep the place reasonably clean, if not always well organized. I keep getting blocked on mopping the floors, though. It's such a huge pain in the ass: sweep, spray some sort of noxious cleaner in the corners, drag out the bucket, fill it with water and a little more of that noxious cleaner, grab sponge mop, mop, rinse, put everything away. So it's been a long time since I've mopped.

I was complaining about this to my sweetie, and she opined as to how everyone had something they get blocked on, be it mopping the floor, cleaning up old code, emptying the basement, whatever. She then proceeded to tell me how she mops floors, and we made a project of it - first to secure proper implements (a basic rag mop, not to be confused with whatever whizbang gadget the marketing people think you ought to have), then a demonstration of the proper technique (fill sink with very hot water and Lestoil, slop the solution on the floor, being sure to get in the corners, let it sit, then repeat once, then rinse the mop, mop up, and dry). And then I was on my own. Sure enough, it worked just like in the movies, and my floors are cleaner than they've been in years. I'm inspired to mop again, when the time is right.

Mopping the floor is an interesting archetype for lots of other chores that we have to do, be they mundane or complicated, housework or business. If you can get past the blockage, either on your own or with someone's help, the results can sparkle, and you wonder what took so long to get around to it.

So it is with the peanut butter. Is it OK to eat peanut butter with a spoon? Bet your ass it is - just have something handy to wash it down with.