Shareware Beach

So how did I find out about the Paris Hilton article?

Earlier this month I received an email from an analyst at a major venture capital firm specializing in software companies, including developer tool companies. He mentioned the article as the way he learned about our company. Funny how stories travel the world and connect people.

Last November at the European Software Conference, there was a panel discussion about venture capital and other forms of financing. Generally, venture capitalists don’t invest in shareware or micro-ISV companies. I learned a new term that VCs apparently use for such companies: lifestyle companies. Here’s one definition I found:

A lifestyle company is one that supports a good living for you, but isn’t designed for an exit (i.e. selling to another company, IPO, etc.) Lifestyle companies are typically smaller, built around the expertise and skill set of the individual founder(s).

That sounds exactly like Just Great Software. But I’m intrigued by the word lifestyle. It means more than just making a good living. It means leading the life you want to lead. According to one dictionary:

A manner of living that reflects the person’s values and attitudes

When you work in a lifestyle company, quality of life, however you define it, comes above all else. In fact, you can’t really work for a lifestyle company. You are the company, whether that’s by yourself or with a group of people as a partnership.

It’s certainly possible for a lifestyle company to bring in a lot of money. In fact, if you do what you love, you’ll put your heart in it. Customers will notice and spread the word.

But as the business isn’t about the money, it’s hard for a VC to make a business case. For a VC, the exit strategy and associated payday is the primary concern. But when you’re enjoying life, an exit strategy is the least of your concerns.

At least, some guy who thinks he is a coding Paris Hilton does. Interestingly, out of the 15 tools he recommends, RegexBuddy and EditPad Pro are the only ones with a price tag (according to the article).

It always makes me happy when somebody likes my stuff well enough to confess to it in public. Not because of the extra sales it might bring. Those are usually minimal, as the exposure is very untargeted. I can trace only one RegexBuddy sale back to the Paris Hilton article. Joel Spolsky mentioning that he uses EditPad Pro resulted in three sales. And if anyone can claim to be the Paris Hilton of programmers, it’s Joel.

What makes me happy is that my work makes a difference in people’s lives. I came up with the name “Just Great Software” eight years ago because that’s what I wanted to focus on: making high quality software. I figured if I focused on making great products, which I love, I wouldn’t have to worry about too much about selling my stuff to make a nice living. And this has certainly proved to be true.

Normally I wouldn’t blog about somebody blogging about me. I’m not enough of a salesman to slap myself on the back in public. And I like my girls with a bit more dignity anyway.

What’s interesting about this article, to me, is not the article itself, but how I found out about it. But that’s a story for after Christmas.

Last month I had the pleasure of meeting Bob Walsh at the European Software Conference. The evening after the conference, a bunch of us had dinner at a Mexican-Italian eatery near the Dom in Cologne.

During our conversation, Bob mentioned that EditPad Pro has been his favorite text editor for quite some time. He said that he got the impression that for the version 6 upgrade, I seemed to have focused on “ticking all the boxes” when comparing EditPad Pro with other popular text editors. Fact is, I hardly ever look at competing products.

My vision is that if I spend too much time looking at other products, I’ll just end up with copy-cat design for my own. It’s easier to design something new when starting with a blank slate than with starting with how things have been done before. At least it is for me. Just like it’s easier to learn a new habit than to unlearn a bad habit.

So how did I decide what to put in EditPad Pro 6 and what not? Easy: customer feedback. Many years ago, I spent an afternoon or two to hack together a simple bug and feature tracking database. It’s just four tables for products, versions, and issues in a master-detail relationship. The fourth table is the reason I rolled my own instead of using an off-the-shelf product. At the time, I couldn’t find anything that could keep a list of customers for each issue being tracked. So if Joe requests feature X, I email Joe a boilerplate “thank you for your feedback”, enter issue X into the database, and paste his email as a vote for issue X. That gives me a good idea of how many people care about X. That in turn allows me to estimate a cost/benefit ratio of implementing X.

It’s not a democratic system where issues with most votes get implemented. Reproducible bugs always get fixed, even if nobody complained, or “Just Great Software” wouldn’t be what it says on the box. Major new features or UI redesigns always get pushed ahead to the next major upgrade. While new features sell, product stability sells too. But when deciding what we have time for, and what needs to wait, customer feedback is a very useful metric.

Of course, Bob wasn’t completely off the mark. EditPad Pro 6 did add a lot of features that are, in some form, available in other text editors. Our customers have seen or even used those editors. “Product Z has X. When will EditPad have it?” is a very common request. But instead of just downloading product Z and plagiarizing the whole feature, I look at why the customer wants the feature. Most customers motivate their requests. Entering the relevant details into the feature tracking database helps to improve the feature’s design. E.g. when people were requesting built-in FTP for EditPad, it was obvious that the need was speed and convenience. The power of a stand-alone client wasn’t needed, because everybody already has one. Hence EditPad 6 got FTP as a sidebar that can stay connected to multiple servers for quick online editing. While that certainly ticks “FTP” on the feature matrix, such comparisons don’t show how happy people are with the feature’s implementation. E.g. had EditPad Pro 6 implemented FTP in a modal dialog, it would have been even less convenient than an external client. (Not that I ever considered such horrible design.)

The cherry on the cake is that collecting email addresses as votes gives you a very valuable means to contact your customers. When a new release fixes a bug or adds a feature that Joe emailed us about, Joe will get an automatic email saying the latest release implements X. Even though the message isn’t very polished (and it apologizes for being so), customers really appreciate this bit of attention.

My recommendation is to worry about making your customers happy rather than ticking all the boxes. Word-of-mouth is far more powerful than a doctored comparison from your marketing department hat.

There has been quite a bit of news lately about companies doing large-scale product recalls, particularly for stuff made in China. By now every marketeer has written his opinion on the expense of such recalls and the impact on the brand names involved.

But what I find interesting is not that QA failures happen, but that manufacturing companies do recall and even replace their products at great expense. This is in stark contrast with the software industry, where bug-riddled products seem to be the norm rather than the exception.

It doesn’t have to be that way. A defective software product doesn’t require a recall in the strict sense of the word. There’s no pile of inventory to take back. All that needs to be done is to fix the bugs, and make the new version or a patch available for download. Relative to a tangible product recall, the cost of issuing bug fixes is nil. Sure, time developers spend fixing bugs is time they don’t spend adding new bugs (under the guise of features) to the software. But that time should have been spent before the product was released. Remember that bugs are a business decision.

For typical consumer and business software, where bugs are annoying and perhaps costly to the user, but hardly life-threatening, the business decision will usually favor an early release to bring in money (unreleased products sell even less than bad products) and beat competitors to market. This doesn’t even have to be a bad thing, if each release is followed up with timely updates or service packs. Then customers can choose if they want to get version 3.0.0 hot off the server, or if they’ll wait for 3.1.0 to fix most of the bugs that plagued the initial release.

But this was going to be an article about recalls. Sometimes, a product or an update is released with a severe bug that makes it unusable to a significant portion of is user base. It doesn’t have to be a total crash or data loss bug. E.g. the initial release of Delphi 2007 had a few new bugs in its Forms.pas unit, resulting in applications with improper taskbar button behavior. While that didn’t stop those applications for working, it made Delphi 2007 unsuitable for the production of “just great software”. But instead of swiftly releasing an update, and an apology, CodeGear dodged the issue with some online articles for changes users could make to Forms.pas (not an easy proposition for newbie programmers) and an official update months later (too late to earn back goodwill).

But it doesn’t have to be that way. About a month ago, I released EditPad Pro 6.3.1. It was a minor update with only fixes and small improvements, so QA was limited to testing the changes and normal everyday use. I didn’t notice any problems, and there were no reports from the early downloaders of the new release. So a few days later the monthly Just Great Software newsletter announced the update to all our customers. To reduce the load on our server, it takes a few days to email everybody.

After the whole list had gone out, I got two support requests claiming that EditPad Pro 6.3.1 locked up completely, seemingly at random. I did a few quick tests, but I could reproduce anything, and the list of changes for 6.3.1 didn’t include anything that could cause lockups. It was getting late, so I called it a day. The next morning it hit me: I had made a change to some threading code inside the editor core for an upcoming release of RegexBuddy (which uses the same editor control as EditPad). This change didn’t have any user-perceptible impact on EditPad, so I hadn’t added it to EditPad’s changelog. Stress testing that code in EditPad quickly exposed the problem. Fixing it was tricky and took a few hours, as I didn’t want to roll back the improvements RegexBuddy needed, and I obviously really wanted to get things right second time around.

And then comes the recall. The bug only occurred in certain situations, and certainly wouldn’t affect everybody. But for those affected, it made EditPad unusable. And it must have been a significant slice of the user base, even though in the end only three people reported it before I fixed it. So EditPad Pro 6.3.2 was published right away. And then I did something that really qualifies this release as a recall rather than an update that’s simply put out there, waiting for customers to be found.

Since our download system requires the user to enter their user ID and email address to generate a licensed copy, we also know exactly who downloads their licensed copy of our software exactly when. That makes it trivial to compile a list of email addresses of customers who downloaded version 6.3.1. It turned out to be a pretty long list, as the newsletter had already gone out. I wrote an email explaining the problem and its severity, asking the customer to download 6.3.2, and apologizing for the whole ordeal. I sent the email immediately to all those who downloaded 6.3.1, and waited for the fallout. It could hardly be worse than having to respond to the same angry complaint of 6.3.1 locking up over and over for the next two weeks. Or worse, having people dump EditPad when it crashes, without checking if there’s an update.

While the recall did result in a bunch of extra support requests, I did not receive a single negative reply. Let me quote you a bunch of replies that people did send:

This bug hit me once yesterday but I blamed Windows XP Thanks for the quick repair work.

[...] Thanks again for sending out the notification email recommending that I immediately upgrade to the new version. This is excellent proactive customer support and I commend you for it.

No apology necessary. “The person who never made a mistake never made anything else either.” Your prompt notification and remedy has reinforced the high regard I have for your software.

A quick response to let you know how much I appreciate your attention to product quality and your dedication to your customers. It is your thoroughness that continues to earn my highest personal respect and my loyalty as a customer.

Oh dear – things happen… But it is one of the reasons I have such faith in your software and your service – an immediate apology and an immediate fix. If only more were like that… Thanks once again for your ever efficient and outstanding service.

Jan, WOW! You are really on the ball! If Microsoft were even half as good, maybe their stuff’d be worth what they want people to pay for it… Many thanks for your kind notice! Frankly, I’d rather do text in Editpad than in Word if it’s amenable.

This is a shining example of your perfect committment to quality! I had experienced the problem, but you solved it before I had a chance to report it. Thanks!

The first and last quotes are particularly noteworthy. There were quite a few more who wrote that they’d encountered the problem, but never emailed for support. And those are probably only the tip of the iceberg of those who encountered the problem, but didn’t ask for support, and didn’t say thanks afterwards. (Nor would I want everyone to say thanks. We’d spend all day sorting out the replies.) But the point is: you can’t rely on your customers to find your software’s bugs for you. Particularly threading issues which happen seemingly randomly often go unreported, as people don’t like to embarras themselves with inaccurate descriptions. (Thinking: “It only crashes 10% of the time, so if I write, it won’t happen to them, and I’ll just get a boilerplate response saying there’s no problem.”)

The customer I quoted first blamed the wrong product. That, and all the other praise, is what a software publisher gets when they really put in an effort to fix bugs quickly. Fixing bugs doesn’t cost software developers money. It earns them money through increased goodwill and increased word-of-mouth, eventually leading to increased sales. Ironically, a developer with a track record of resolving problems quickly can more easily get away with shabby releases than a developer without such a track record. If 1.0.0 doesn’t work well, nobody minds waiting for 1.0.1 or even 1.0.5, if they know they’ll get it soon enough.