Nick Bradbury

Anti-social FeedDemon (Killing Features, Part II)

Last night the changes to Google Reader went live, and as promised, they've removed the sharing features. This means that the sharing features in FeedDemon which rely on Google Reader will eventually stop working, so I'm forced to remove them.

A few years ago I wrote about the pain and pleasure of killing features, but deleting sharing from FeedDemon has been all pain and no pleasure. Those features took a long time to create, and I relied on them every day. Seeing what my friends are sharing, and sharing back with them, has become part of my daily routine.

I don't fault the Reader team for removing those features - it makes sense for Reader to integrate more tightly with Google+. And I certainly don't fault them for eventually removing those features from their unofficial API. If anything, I want to thank them for letting developers such as myself use their API for free for so long.

But I'm surprised that the Reader team didn't make the transition to Google+ an easy one. I realize that Reader users are a dwindling bunch, and most of them never used the sharing features. But many of those who relied on sharing are influencers, including well-known tech journalists, bloggers and developers. It strikes me as a bad idea to leave these people with a sour first impression of Google+, yet that will be the result of the painful transition from Reader sharing to Google+ sharing.

As far as FeedDemon goes, in a few days I'll have a build ready which removes the sharing features. But I'm going to hold off releasing this build for a little while since sharing still works at the API level. In other words, right now you can still use the Reader sharing features in third-party apps like FeedDemon even though those features aren't available in Reader itself.

Before the end of the year, though, there will be a new FeedDemon release which does away with sharing, and every FeedDemon customer will need to upgrade. That pains me, because like every developer, I'm used to having new releases improve upon previous ones. For some this release will feel like a downgrade, and I know I'll take some heat for it since many customers won't be aware of the reasons for the loss of sharing.

Tiny Apps are Hard

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.

From Windows to Android with Glassboard

Earlier this year I got an offer I couldn't refuse. Several friends and former co-workers of mine were forming a company named Sepia Labs, and they asked me to join them. They planned to create a mobile group sharing app, and they wanted me to develop the Android version.

I've been itching to get into mobile development for a long time, but I didn't even own an Android, let alone know how to develop for one. Yet there was no way I could turn down the chance to learn mobile development while working with people I know and respect.

So I joined Sepia Labs, and we immediately set out to design a different kind of mobile group sharing app, one that values privacy above all else. The end result is Glassboard, which we launched today for Android and iPhone, and will soon be available for Windows Phone 7. I'm really proud of what we accomplished with Glassboard, and I hope you'll give it a try (and after you get it, this post will help you get started).

Now, I can tell you that switching to Android wasn't easy after almost two decades of Windows development. I had to learn a new language (Java), a new IDE (Eclipse), a new platform (Android) and a new programming mindset (mobile) in a very short time. Oh, and just to make it harder, I decided to do it all on a Mac. I guess you could say I was looking for a challenge :)

And a challenge it definitely was.

The first challenge was trading my iPhone for an Android. I've used an iPhone for several years, and my new Android felt unpolished and geeky by comparison. But I slowly warmed to it, and now I love my Android so much that on the rare occasion I pick up my iPhone I curse it for not having a back button.

The second challenge was learning Java. My usual approach to learning new things is to just jump in and get my hands dirty, but I decided not to do that with Java. Instead, before I wrote any code I read a ton of books on the language (my favorites were this one and this one). I had Java books all over the place - on my desk, next to my bed, in my car, and in every bathroom of the house. I wanted to really understand the language before I used it so I could design Glassboard correctly (and not have to redesign it a dozen times as I learned more about Java). Surprisingly, I liked Java right away. It does feel a little too object-oriented sometimes, and it was hard getting used to garbage collection and the C-like syntax, but it made sense to me. It's a very well thought out programming language.

Next I had to figure my way around Eclipse so I could actually write some Java code. Like Nick Farina, I absolutely hated Eclipse at first. I despised its strange, overloaded user-interface. I made up new swear words as I stumbled around trying to decipher its overwhelming array of menu items. But I've definitely grown to appreciate Eclipse. It has some incredibly powerful features that I haven't seen elsewhere, and it rarely gets in my way - in fact, it actually helps me write better code. And funny thing is, when I work on FeedDemon now, I wish that Delphi had the features I've gotten used to in Eclipse.

I thought my biggest challenge would be switching to the mindset of a mobile developer, but that hasn't been nearly as hard as I expected. I've written for years about simplicity, killing features and doing away with options, all of which are requirements for mobile development. Mobile development forces you to focus on exactly what your software needs to do, and I really enjoy that.

But developing specifically for Android has been a huge challenge. There's an awful lot to learn - intents, activities, AsyncTasks, XML layouts, services, BroadcastReceivers and on and on and on. Once you wrap your head around everything it all makes sense and fits together well, but getting to that point doesn't come quickly. And as is always the case, the thing that takes the most time is learning your way around all the gotchas. If you're just getting started with Android development, be prepared to spend a lot of time on StackOverflow!

Of course, I can't write my first post about Android without mentioning its supposed "fragmentation" problem. It is a problem, but it's mostly blown out of proportion. Desktop developers have always had to create software that works across different OS versions, different devices and different screen sizes, so the fact that you have to do that on Android isn't a big deal. But it is a big deal when different Android devices handle things differently - video playback and recording, for example, are challenging due to device differences, and getting video streaming to work reliably across devices feels impossible (as Netflix discovered).

All in all, learning so much new stuff in such a short time has been both thrilling and exhausting. I'm finally doing mobile development, something I've wanted to do for years. But take it from me: if someone offers you a job that requires switching from Windows to Android development and learning it all in a few months, stock up on the caffeine - you're going to need it!

PS: Hopefully this post explains why it's been so long since there was a new build of FeedDemon. I am still working on FeedDemon, and a new release is already underway.

Some Customers Suck

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.

Not an Option

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.

Thinking Out Loud: What Should I Learn Next?

Now that I'm an independent developer again, I've been giving a lot of thought to what I should learn next.  I still love Delphi for developing Windows desktop apps, but I've been doing that for (holy shit!) 15 years now and it's waayyy past time for me to update my skills.

I had been leaning towards iPhone development, and I even attended Macworld to get a feel for the development community.  But as wonderful as the iPhone developers I met were, I'm completely turned off by the way Apple handles their App Store.  Having a one-stop shopping source for the iPhone is great – I'd love to have something similar on Windows so customers wouldn't have to fill out their personal information every time they want to buy software online – but Apple's lack of respect for their developers killed any interest I have in iPhone or Mac development.

The obvious choice, then, is for me to drop desktop/single-device development completely and create web-based software.  Nothing for customers to install – they just browse to a URL to use my app.  The trick, of course, is to create a web app that people are willing to pay for.  I'm not one of those developers who wants to rely on VC financing to stay afloat while they figure out a business model, and I'm far from convinced that every web developer can earn a living from advertising (yes, I recognize the irony of me saying that).  Having a family to support sort of kills the willingness to create something and hope it somehow makes money down the road (I mean, have you seen the cost of health insurance these days?).

Strangely enough, I find myself leaning towards sticking with Windows development.  I say "strangely enough" because I have a love/hate relationship with Microsoft, and I cringe every time I see a Microsoft app favor geekiness over simplicity and usability.  But lately I've been impressed with what they're coming up with.  Their moves with Azure, Silverlight and .NET are impressive and show that they're not down for the count.  For the time being it may not be "cool" to develop for Windows, but if you care about being cool, then WTF are you doing being a geek in the first place?  I'm perfectly fine being anti-cool if it enables me to keep my family covered and develop software that tons of people use.

So…if you've read this far, then there's a good chance you're a developer and not just someone who uses my software.  If so, what would you do in my shoes?  What platform and development tool(s) would you focus on now?

Why I Use Delphi

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.

HomeSite Discontinued

Last night I found out that HomeSite has been discontinued.

I was surprised to hear this, but not because I thought it was premature – truth is, I was surprised HomeSite hadn't been discontinued a long time ago.  It's been almost 15 years since I created HomeSite, and I stopped working on it in 1998 when I left Allaire Corporation.  Several other developers took over after I left, but to the best of my knowledge nobody has touched it for several years, so the fact that it was still being sold until now is a nice testament to how useful people found it.  Kudos to Macromedia and Adobe for keeping it around, despite the fact that it competed with some of their other products.

Sometimes in this blog I've made disparaging remarks about HomeSite, but that's not because I disliked it.  It's just that it's hard to look at something you created so long ago without seeing all the mistakes that you've learned not to make since then.  I'm actually very proud of HomeSite, and very thankful that it enabled me to quit my job and work at home.  And, funny enough, HomeSite is also what paid for the home I'm living in now.

I'm also incredibly thankful to the great community that sprang up around HomeSite and helped make it so popular.  The Wikipedia page on HomeSite captures a bit of this history:

"Nick Bradbury and then Allaire had a policy of having an open support forum for those interested in its products, both current customers and prospects. The fans of HomeSite would contribute to the development of the product by making suggestions on-line and refining those suggestions amongst themselves. The Allaire developers would join in the discussion, participating and really incorporating user suggestions…Users responded to that respect and love for the tool by supporting each other and by creating and sharing a wide variety of HomeSite extensions."

These days it's common practice for programmers to actively involve customers in the creation of their software, but back in 1995 it wasn't the norm.  I certainly wasn't the first developer to take this approach, but I like to think I was one of the pioneers.  That more than anything is what I'm most proud of with HomeSite: in some small way, I hope I helped to break down the invisible wall between developers and users.  So much of our society's future depends on technology that we absolutely must open the lines of communication between those building the tools and those using them.

Anyway, I hope you'll forgive my patting myself on the back a bit here.  I've never had one of my creations go the way of the dodo, so I'm feeling a bit nostalgic at the moment, and I'm looking back and remembering the things (most of them accidental) that got me started down this path I'm on.

Update: I have to add that TopStyle 4.0 is an excellent replacement for HomeSite. It even has the tabbed HTML toolbars that were so popular with HomeSite customers.

If You Want to Write Useful Software, You Have to Do Tech Support

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.

Download Size Still Matters

Is it just me, or has the size of downloadable software ballooned ridiculously over the past few years?

Call me old school, but this bothers me.  It’s like some developers assume their software is so damn good that it’s okay if it takes a long time for you to download it.  Their software is so fantastic that it deserves to occupy a ton of space on your hard drive.

Yes, I know, hard drive space is cheap, and high-speed internet is supposedly everywhere these days.  But that’s not the point. 

The point is this: if you’re a desktop developer, then your software has to compete with web applications.  You know, those applications that you run by simply typing a URL into the address bar?

Can you imagine typing www.google.com into your address bar and then waiting for a couple hundred megabytes to download before you could use it?  Can you imagine visiting a web site that required you to reboot your computer?  Or one that required you to install a ton of updates before you could visit it?  How popular do you think these sites would be?

If you’re a desktop developer, don’t make the mistake of thinking your software only competes against other bloated desktop applications.  It also has to compete with web applications that don’t require downloading anything. 

The days when you could get away with a 100+MB download just to try out your software are long gone.  You want to stay competitive?  Shrink your download and streamline your install.  Make the download so miniscule that trying it out is a no-brainer. 

PS: The latest FeedDemon 3.0 beta is a 3.4MB download :)