Making software simpler for end users is incredibly important, but sometimes simplifying your software means making things simpler for you, the developer. And the best way you can do that is to avoid adding any feature that would bury you in support costs.
I’ll give you an example: a number of FeedDemon customers have asked for an integrated blog publishing tool, which certainly sounds like a good idea. However, I’ve avoided adding one because it would be too hard – and I don’t mean too hard to develop, but too hard to support.
Most blogging services enable third party applications to post to them through a “standard” API, but I’ll wager that every developer of a blog posting tool has experienced hair loss trying to deal with all the creative ways that blogging services support this API. And they must quake in their boots when they hear that a popular blogging service is coming out with a new version, since that often means changes to how external tools post to them. These developers probably spend a huge chunk of time dealing with “bug reports” that are caused not by their application but by changes to blogging services.
If blog posting was FeedDemon’s primary purpose, I could accept this support burden. But it’s just one feature among many, so it wasn’t worth it. I figured I was better off integrating with third-party tools that provide the same functionality.
So before you add that cool new feature to your software, take a minute to consider whether the benefit to your application is worth the time you’ll spend supporting it. You don’t want to find yourself unable to keep up with the competition because you’re spending too much time supporting features you didn’t really need to add in the first place.
Hair? What hair? ;-)
How about a plugin system so that 3rd party developers can develop a blog plugin?
Just a though ;)
Nick, I for one applaud this decision. FeedDemon is a content consumer, not a content producer. I’d much rather see you invest your time in making FD even better at consuming content, rather than wasting time also making it able to produce it.
I am sure there are plenty of applications out there that focus on making their applications produce content and happily ignore the consumption side.
Nick,
Quite right! Far too many applications are in danger of becoming bloatware because the developer has added functions that are wanted by a small subset of users, and new “improvements” have to be coded each time something changes.
Another good example is TopStyle’s “lack” of FTP support. Another xHTML application which includes it keeps bringing out updates to get around problems discovered in the way different servers act, wasting the developer’s time which could be used much more productively in improving the core functionality: coding xHTML.
Alan, my “no integrated FTP” stance with TopStyle is a great example here. It wouldn’t have been hard at all to implement it, but I knew from talking with developers of standalone FTP clients that I’d be deluged with support problems caused by non-standard FTP servers. So I figured I was better off not adding this feature.
Well said. And I agree. Way to put first things first.
Hey Nick,
Well said. I’ve been using TopStyle on and off for years (depending on what I am doing) in its different flavors, free and paid.
I’ve found it to be a useful tool because it does what it supposed to well and doesn’t try and do everything. I feel like it streamlines my development process. It also doesn’t need to be integrated with anything in particular and it certainly never breaks.
I’ve been looking for other focused tools like this for quite some time.
Kudos on you tool and stance.
Geoffrey