There are a differentiating factor when you write an app for "jingles" and when you write an app for the "jiggles". In the former where money is concerned, time to deliver is of utmost importance. So you may have to cut some corners in terms of features; You might have to take the easiest route, one that works even if it might not be the best solution. However if you are writing an app for fun of it, then learning and doing it the right way should the main focus.

In the "app aimed at a very specific need" camp, I've often found that inspiration for an application can come from needing, as a user, to find an application to solve a particular problem, only to discover that the applications that already exist only meet (at best) 80% of my needs.

I loosely apply the principle of the categorical imperative and assume that if the remaining 20% of functionality is important to me, it's probably important for a number of other people as well.

In a given field of applications, the baseline functionality that all of the applications deliver can be thought of as "basic needs". Whatever terms describe this baseline functionality are the same terms that people will use to find your application, whether through a web search or browsing through the Apple Products Guide. Your application needs to address the same basic needs as competing apps, but preferably in a more elegant or user-friendly way. The problem with innovating in the area of basic needs is that potential users of your application may not ever get the chance to weigh your more elegant approach to basic needs against a better-known competitor, so you shouldn't focus too much of your effort on the "better mousetrap" problem.

Basic needs cover 80-90% of the functionality; unspoken needs (also called "delighters") make up the balance. Here's your chance, as a developer, to really shine; by innovating around a need that no one is addressing (my missing 20% above), you can distinguish your application in an immediately obvious way and, potentially, address the needs of a large enough user base to get some traction.

The trick is that over time, "delighters" transform into basic needs. What once made an application stand out in a field of competitors is now addressed in more or less the same way across that field. So your application is never finished, and you must either continue to innovate, or abandon the cause altogether.

I'm writing an app that is probably only useful for me, as the need is so specific, but since I've been trying to learn the art of programming on the Mac, programming the app is its own reward, as I'm learning all the basics plus things like Sync Services.

Actually, one of the reasons I think that Apple apps are so great is that they actually apply the 80% rule differently than the poster above. They also mention it in their programming guide somewhere. The trick is to restrict yourself as a programmer and only include functionality that >80% of the users will use. This helps to keep the app from becoming bloated with functionality that hardly anybody uses.

This response is a bit late, so people (other than scott) probably won't see it, but…

Corey: I think that's a really insightful take on the best-of-class apps, and it clarifies my thinking on the subject.

PGM: No, Corey is exactly right, and this applies to Apple's apps as well. In fact, I think your 80% rule and Corey's 20% are completely consistent with each-other. The idea isn't to pile on features that 1% will use, but to find those features that everyone needs, but no app is currently providing. 2 examples:

1. Aperture: Apple looked around at the digital photo manager/editor market, and noticed a gaping hole. While Photoshop had, and has, the market for retouching, special effects, etc. all tied up, no shipping application had seriously looked at the workflows of digital photographers. Applications like iView, Cumulus, and Adobe Bridge are basically glorified file managers, and they approach the problem as one of files with thumbnails and folders. The Aperture team looked around at the newly available fast hardware, and at the RAW images coming out of modern digital cameras, and then sat down with the disgruntled photographers forced to use these other apps, and together mapped out a new product that would be based around images, using physical metaphors like light tables, but extending their power with computers. This is a feature set and indeed, a whole outlook that other developers had completely missed, and the result is a true delight.

2. Textmate: Allan Odgaard looked around 2 years ago, and was unhappy with Xcode's pretty basic text editor (basically halfway between TextEdit and Mike Ferris's TextExtras input manager. He also didn't like the command-line unix editors (vim, emacs, etc.), wanting to keep to the GUI and the Mac philosophy on his shiny G4, and felt constricted by the philosophy of BBEdit. So he went out, looked around, and found text editing patterns which he felt should be automated by the computer, but weren't by any existing app, and set out to fix that. The result, TextMate, has the most easy-to-understand yet powerful, orthogonal, abstractions of any editor I've ever used.

When it comes to pure feature checklists, there is no way for a new product to ever line up as many boxes as existing dominant applications. Also, they wouldn't want to, because in general, lots of those features are crufty and obscure. Instead, the goal should be to provide powerful new abstractions that every target user needs, without even knowing it.

The title alone makes me scratch my head in wonder. It's like me deciding that I want to become a carpenter, but I have no idea what to build. Then again, I tend to have too many ideas that I work on, which can create its own set of problems by dragging my attention in too many different directions at once.

For the smaller developers, they should focus on something that interests them and which they personally find useful. Otherwise, if you are just looking to make money, there are plenty of companies out there that will pay you to program some boring internal application for them.

I decide what application to write by deciding if I know a subject well enough to be useful. The standard advice to young authors is to write what you know most about. The problem with this is that since most programmer's know code development, we find ourselves surrounded with editors, scripting languages, compilers, operating systems, and IDEs.

Elegant solutions to problems previously solved gives a boost to the ego. Jacob obviously appreciates and gives kudos to Allan Odgaard for his work on Textmate, but it is still yet another ...

God often blesses us with hobbies so that we are able to earn a living. Many, such as myself, a mechanical engineer, came into program development from other disciplines. This makes us the best suited to write applications for those disciplines. Crossing the boundary from all most any (a)vocation to program development allows the author to know of the possibilities of the computer platform and the needs and wants of the non-programmer.