Category: Software

When I started writing mobile apps, I figured, how hard can it be? Apps look dinky on the small screen, so it must be easy to create them.

But holy shit is it hard.

It's hard on Android, on iOS, on WP7. And from what I hear, it's even harder on Blackberry.

It's almost like the MS-DOS days when you had to figure out how to squeeze every last ounce out of the machine to get your stuff to work. Except now you also have to make your app look good.

But you know what? I'm loving the challenge. I've been developing desktop apps for so long that I just assumed I could keep adding feature after feature and option after option without worrying that I'd tax the system.

Now that I'm a mobile developer, I'm finding it strangely wonderful to have to consider things like battery life, reduced screen real estate and limited storage space. I'm forced to make sure that anything I add to my app is important, because if it's not important then it's not worth the trade-offs.

Regardless of whether I stick with mobile development, the lessons I've learned from it are ones I'll apply to everything I create in the future. Keep it simple, keep it uncluttered, and keep it focused. That's how you create great apps for any platform.

After reading David Frampton's rant about the impact a small minority of mean-spirited customers has had on him, I wanted to send him an email saying that it'll get better.

But I couldn't do that, because it won't get better.  I started selling software on the web in 1995, and the problem of nasty customers has plagued me since day one.

Don't get me wrong: I've talked with enough other developers to know that I've had it easy compared to many of them.  The vast majority of my customers are great to deal with, even when they have a complaint.

But there's always that small fraction of customers that suck. 

They're used to dealing with companies that sell them crap and then ignore them, so they treat it as a rare opportunity to vent their frustrations when they find a company that actually has a real person answering questions.

They toss insults at you, threaten to bad-mouth you all over the web, post mean-spirited reviews on download sites, and demand IN ALL CAPS that you change your software to meet their needs RIGHT NOW OR ELSE.

When you try to help them, they just get worse.  And they do this even if they've never paid you for your work, and never plan to.

Being forced to deal with these miserable people is enough to make you want to stop providing support, but that's a mistake.  I've always believed that the key to creating great software is to talk with those who use it, to understand what they need and want from your product.  If you step away from support, your software will suffer.

You can, however, step away from bad customers.  If they have a valid complaint, sure, address it, and treat them with the same respect that you wish they'd show you.  But if they bad-mouth you over something very minor and demand that you reply immediately, either wait a little while before answering or just ignore them completely.  You're better off without each other.

The worst thing you can do is let these people ruin your day.  After all, it's not like they're making you look bad.  Think about it this way: if you go to a store and witness someone screaming at the cashier, who looks worse? Everyone knows the customer is being a jerk, and they feel sorry for the cashier.

I've been able to keep doing this for over 15 years by understanding that these people aren't just unhappy with me: they're unhappy in general.  You can't change that, and you can't let it change you.

It's hard to say no to your customers, but I'm getting a lot of practice at it.

You see, almost every day I say no when a customer asks me to add a feature to FeedDemon.  It's not that I don't want them to be happy – it's just that every feature I add to FeedDemon potentially makes it more complicated for every customer, so I have to shoot down features that I don't believe will be widely used.

Quite often, the customer will reply with, "well, why not just make it an option?"  Which of course makes sense when you're thinking about one little feature.  I mean, how could adding one measly checkbox tucked away in the program's settings make it more complicated?  But multiply that by the number of feature requests I get, and it becomes clear that making everything an option is, well, not an option.

I wasn't always this way.  Many years ago when I worked on HomeSite (and, to some extent, TopStyle), I'd say "yes!" to feature requests all the time.  If the feature wasn't one that a ton of people wanted, I'd just make it an option.  I thought this was great – and at first, it was.  Customers got new stuff all the time, and loved seeing their suggestions included in the product.  But fast forward a few years, and suddenly my software was an option-laden monstrosity.

In a misguided attempt to please everyone, I had added page after page of checkboxes to the options dialog.  Customers kept asking for options that already existed, or wondered where an option was that they knew was there but couldn't find in the checkbox maze.  Even worse, they'd inadvertently enable some option that changed the program's behavior, and then report that the software no longer worked like it was supposed to.  Which meant that when I received a bug report, I'd have to figure out which options might be involved in the bug, and then figure out which of those options the customer had enabled.

The other thing is, while it's easy to add an option, it's very hard to take it away.  If you add an option to your software, you'd better be prepared to keep it around for the life of the product unless you want customers coming after you with pitchforks and torches.

For example, in the first version of FeedDemon, I added a few options that made sense at the time, but later on weren't being used much and were complicating the development of new versions.  So in the first few beta versions of FeedDemon 4.0, I did away with some options that had existed for years.  To say this wasn't received well would be an understatement.  Customers who had become used to these options were up in arms, and said they'd never upgrade if the options weren't returned.  It's pretty frustrating for a developer to hear that all the work done to improve a product is overshadowed by the loss of a few options that probably shouldn't have been added in the first place.

So if you're a developer and you're working on a new piece of software, don't make my mistake of adding options, especially if you're doing so just to please a handful of power users.  In fact, see if you can avoid the need for a settings dialog at all.  You and your customers will be happier in the long run.

Every now and then someone will ask why I develop my software using Delphi.  After all, there are more "modern" languages for Windows like C#.  And besides, Delphi is going to die eventually, right?

Funny thing is, 15 years ago when I was developing HomeSite I was getting razzed by some geeks for using a development tool that they said would soon disappear.  And yet 15 years later I’m still going strong writing software in Delphi.

Here’s why:

1. Speed.  Delphi isn’t an interpreted language – it compiles to machine code, making it exceptionally fast.  Delphi’s string handling is particularly fast, which is important when developing a string-heavy application (such as HomeSite, TopStyle or FeedDemon).
2. No runtime. Languages such as C# and VB.NET require the .NET runtime, which is a separate 20MB+ download for customers that don’t already have it.  I don’t want to worry about whether potential customers have the .NET runtime installed, or have the correct version installed – I just want them to download my software and use it without any additional headaches.  The latest version of FeedDemon is a mere 3.4MB download (yes, download size still matters), and no additional download is required.
3. Startup time. Related to the above, well-designed Delphi applications start quickly because they don’t have to wait for any runtime to load (assuming it’s not already loaded).  To me, this is a critical benefit.  Applications that take a long time to load have a low perceived performance, regardless of how fast they are once they’re loaded.
4. It’s not created by Microsoft. Don’t take this as vague Microsoft bashing, because I like much of what Microsoft does (if I didn’t, I wouldn’t write software for Windows).  However, past experience with Microsoft development tools has taught me that they’re willing to sacrifice the needs of developers in order to push forward their agenda.  I like the fact that Delphi is created by a group of dedicated programmers whose single goal is to make it the best development tool possible.

I realize that many Windows developers are put off by the fact that ownership of Delphi has changed hands so many times, but I see that as a testament to how strong the Delphi community is.  By many accounts, the latest version of Delphi is the best yet, so if you’re writing software for Windows and are lucky enough to be able to choose your development tool, you should give Delphi serious consideration.

BTW, I’m far from the only one to develop a popular application with Delphi – for example, Skype, Ad-Aware and Macromedia Captivate were also developed with Delphi, and there are plenty of other well-known Delphi applications.

Before I fell into the world of shareware, I worked in the bowels of corporate America developing client-server applications.  And I hated it.

Perhaps the thing I hated the most was that I rarely talked with the people who ended up using my software.  I was given a list of requirements, told what was expected, and that was it.  I never found out whether my work met the needs of those using it, never got to ask them how I could improve it, never knew if my software was a blessing or a burden to them.

Apparently that was smart business, because the companies I worked for charged their clients an obscene amount for my work.  But it was a lousy way to write software.  The whole point of writing software is to create something useful – to create something that, even if in a small way, makes someone’s life better.  And how can you know whether you’re doing that if you don’t talk with the people who use your applications?

I broke out of corporate development by getting lucky with HomeSite, which I never expected to become as successful as it was.  Looking back, it’s clear that its success wasn’t because it was a “killer application,” but because I opened the floodgates and directly communicated with my customers.  By talking with customers I helped ensure that it met their needs, which is the best any developer can hope for.

It seems so obvious: if you want to develop software that’s useful to people, you’ve got to talk with them.  But too many developers take the anti-social approach and consider customer support to be beneath their status.  Besides, talking with customers would distract them from important code-slinging.

Look, I can understand that viewpoint, especially if you’re working on something that’s very popular.  You can’t create anything if you spend all your time doing support.  But avoiding support completely is a big mistake. 

If you’ve never supported your own software, spending just one day doing tech support will be an eye-opening – not to mention humbling – experience.  You’ll have to keep your ego in check, because most people who contact tech support do so because they’re having problems with your software, some of whom will use colorful language to describe the annoyances they’re running into.

But that’s the stuff you need to hear.  You need to hear it because you’re the one who can solve those annoyances.  You’re the one who can get rid of all the things that prevent your software from being that kick-ass program that people recommend to their friends and co-workers.

You also need to hear an unfiltered view of what people want your software to do for them.  If you rely solely on your tech support team to tell you the features that customers want, chances are you’ll develop those features without really knowing why people want them.

And that’s not meant as a criticism of your tech support team.  When NewsGator was still doing tech support for FeedDemon, they did an excellent job of answering people’s questions and forwarding feature requests to me.  But I would still follow-up with customers to figure out exactly why a feature was necessary, and quite often it turned out I didn’t really need to add a new feature, but instead needed to change how an existing one worked.  A lot of feature requests were the result of people being annoyed with how an existing feature worked, and they wanted some way to get around it.

If you really want to write useful software, stop spending all your time keeping up with technology.  Don’t worry if your resume isn’t filled with the latest buzzwords.  Instead, invest your time in talking with your customers. They don’t care what programming language you use – they only care whether your software meets their needs, and the best way to ensure that is by breaking out of your cone of silence and opening the lines of communication.