Posted By Paul Kafasis on July 15th, 2003

Major corporations have bylaws. Doctors have the Hippocratic Oath. At Rogue Amoeba, we’ve got Good Ideas. I now present to you…

Rogue Amoeba’s Good Ideas – You can tell they’re important, because all the words are capitalized.

All Killer, No Filler

First, we think this one sounds cool. What it means is that (hopefully) every feature is a good feature. If there’s no reason to add a feature, we don’t add the feature. Feature bloat shouldn’t happen for a long time, especially on a small application. If we really work, it doesn’t need to happen at all, but I can’t claim that we’ve attained that level of perfection. I do know you won’t ever find Clippy in one of our apps.

Release Early, Release Often

The easiest way to stay on the radar is by having our product on the update sites (like www.macupdate.com and www.versiontracker.com) consistently. These sites are free to post updates on because they want to list the most recent versions of applications. Releasing intermediate releases, like 1.1, and 1.1.1, gives us more exposure on this pages. This in turn steadily increases our user base, with peaks on major releases when we do the most advertising and PR. We aim for at least one release (total) per month, and as our product line grows, this number probably will too. By releasing often, we stay in the habit of releasing, and we get feedback more often on our apps. This leads to two benefits – increased development and faster bug fixes. Because of the feedback we get after a release, we keep working to make our apps perfect and in tune with what users want. And because we’re constantly releasing updates, we get bugfixes out there quicker, which is a must for my sanity, since I handle the support mail.

Minor Releases Are Still Major Releases

This goes hand in hand with Release Early, Release Often. It’s important to remember that every release brings new users to your application, and that they’re seeing your product for the first time. Because of this, a 1.2.4 release is important, just like a 1 .0 release. It needs all the polish and packaging of a major release. It doesn’t necessarily get as much publicity as a 1.0 or a 1.5 type release, but just as much care goes into what people will see when they download the application.

We Are Not Our Users

We use our own products, generally on a daily basis. However, we’re very biased about them. We use them over and over, testing each and every possibility to make sure everything works as expected. Because of this, we are all extremely over-experienced with our applications, and because of this, we must constantly remind ourselves that We Are Not Our Users. This is particularly important to remember when we create our user interface, as well as our web sites and documentation. And it’s probably the rule we forget the most. But we try, and we’re continuing to try, to make our applications accessible to everyone

This rule also applies to features. Sometimes, we have strange uses for our applications, uses very few customers would care about. In such an instance, it’s important NOT to add a feature specifically for this use, just because we might like to have it. Our users needs come first, and that goes from not cluttering the app with our own obscure features to what gets implemented first.

Under Promise, Over Deliver

This is a Good Idea for how to live, not just how to run a company. It’s said, by me at least, that a Pessimist is never disappointed, and an Optimist is never surprised.This is certainly true of customers. Prior to an app’s release, we don’t like to create a lot of hype about it. We may announce some basics about it to get people interested, but beyond that, we don’t pump something which doesn’t exist.

Most importantly, we never (ok, almost never) say with certainty that a feature will be in the next version. Everything we say to customers is read as a guarantee, a promise, and if we don’t manage to out that feature in the very next release, we’ve broken our word. We’re better off saying that we like the idea and will try to include, but that currently, it’s not there. If we lose a sale because of this, that’s ok. I’d rather lose a sale but keep a happy potential customer for the future than make one quick sale now and piss off that customer (who has now given us money and to whom we are somewhat indebted) by not giving him the feature he believed was coming. This relates well to a previous posting here on UTM.

Good Enough Can Be Good Enough

The world is grey and there are generally more than two sides to an argument. Right and wrong aren’t usually as clear cut as we’d like. Often times, there’s a problem in one of our apps which requires a solution. And often times, we have a quick solution which isn’t perfect. However, it’s Good Enough. We strive for perfection, but it’s not always possible. Time is expensive in both real and opportunity cost, so we must sometimes accept that Good Enough Can Be Good Enough.

Development Never Stops

It used to be the rush was to get to 1.0. In the .com bubble, everyone was racing to be the first on the block to unveil the latest technology. Now, the market’s thinned out, and the great new ideas are fewer and farther between (Or at least, the claims of them are). The Audio Hijack concept was out in various forms for over a year before Audio Hijack 1.0 was released. The key is no longer to get to 1.0, at least not for us.

Reaching a 1.0 is a milestone. But it’s no longer the milestone. We develop a product for weeks, months before our 1.0. But hopefully, a product exists after its 1.0 for years. And during this time, Development Never Stops. We don’t ever think one of our applications is complete – if we want to stay on customers’ radar, we need to keep updating. We need to fix bugs, update for new OSes, and keep adding features (See also Release Early, Release Often). As long as they’re Killer.

There you have it – the 7 Good Ideas of Fairly Effective Amoebas. Let us know what you think.