Brent Simmons talks about the pain and pleasure of deleting features from your software:
I hope it’s self-evident that apps with too much stuff are, in general, bad. And that there are some features whose time has come and gone, and there are features that don’t get used much.
When working on a new version of the app, before I think about the features I want to add, I take a look at what I can get rid of first. It’s a quality-of-app thing. I think of it as making space for the new stuff — but first I have to take the wrecking ball to some old stuff.
Killing features should be a part of almost every developers’ playbook, but all too often it isn’t. We’re so used to adding new stuff that we don’t think about getting rid of stuff we’ve already added. A few years later, we find we’ve created an application so bulky with features that only pre-existing customers can understand it. New users are so overwhelmed that they look for something simpler.
When I delete a feature, I’ll often do it in an early beta version, and then never mention anything about it. If by the end of the beta period nobody notices that it’s gone, I’ll know that it wasn’t being used and I’ll remove it for good. Or if only a few people mention it, and none of them say it was an important feature, then it stays on my kill list.
Sometimes I get it wrong, though. I may remove a feature that I think isn’t important, only to discover that a ton of people relied upon it. So I resurrect it in the next version (although I often hide it to keep it from adding to the app’s “feature heft”).
Of course, if you find yourself wanting to delete a lot of features from your app, then you need to be more cautious about adding them in the first place. This was a mistake I made with early versions of HomeSite. I was new to commercial software, and I thought that in order to succeed I needed to make everyone happy by adding anything and everything that was requested. Sure, power users who requested a feature that got added were happy at first, but a few versions later, HomeSite was a toolbar-laden monstrosity. It was supposed to be a simple application for hand-coding web pages, but I’d turned it into something that overwhelmed new users.
You’re kidding right? HomeSite was and still is one of the best web development tools up to and including Dreamweaver CS3. I still use it today!
Feature creep aside, HomeSite was in its entirety awesome. It’s the only product that could, in breadth and individual component capability, rival Coda. Furthermore it’s probably the only product not made by Microsoft that could legitimately adopt the Ribbon because it needs it and not just because “hey let’s all go look like Office”.
Those tabbed toolbars are a dead ringer for the Ribbon anyway. :)
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Antoine de Saint-Exupery (French writer (1900 – 1944)
I’ve had similar thoughts, although not nearly articulated as well. One of the product families is undergoing an upgrade, and I wanted to do some trimming before adding anything new. But, what to trim? So I put a survey up on our web site for existing customers, and another for general users that was promoted with a PRWeb release. However, so far, the response has been anemic, but the surveys have three more weeks to run. I’ve also been thinking about adding instrumentation that is fully disclosed, and with an optin, during the installation dialogs, and a confirmation whenever the summary is sent. I’m not sure what the customer reaction will be, but will post an added comment here when I get some indication.
Thanks for the great post. i
It inspired me to write a relevant post http://zero2beta.com/?p=42 that has to do with an experiment we’re doing “Zero2Beta, release a web app in 2 days”.
I agree that apps should not become too bloated, and one way round this is ot use extensions and plug-ins aka Firefox, that way it is up to the user to decide which extension or plug-in he wants to use, and let the developer deal with the basics of the program.
Bob
@Bob: I’m torn about plug-ins. For apps like Firefox, they obviously make a lot of sense – there are tons of users who stick with Firefox for the plug-ins alone. But at the same time, plug-ins greatly increase the risk of crashes, which can lead people to dump your product entirely.
In addition, a plug-in architecture often requires a decent level of backwards compatibility, which can seriously complicate coding and slow down its development (esp. for apps that don’t have many developers).
I wrote along a similar line previously – see http://nick.typepad.com/blog/2006/12/extending_your_.html
@Jesper: I think you’re absolutely right that HomeSite would benefit from a Ribbon UI (and so would TopStyle, for that matter!)