Everyone has their own delusions of grandeur. The ill-conceived notion that somehow, this editor, mail client, web app, or game I just conceived of 15 minutes ago is going to make it big. Before I start, I'd better buy a domain name and set up a bug tracker and three mailing lists. Remember splash screens?
Fortunately, most veteran developers have grown above the overt expression of such hopes. But that doesn't mean they don't present themselves in another, more subtle way: the unreasonable expectation that it is reasonable for a minor application to consume an inordinately large fraction of a user's life.
Over the course of an average day,, I probably make direct use of some tens of difference of pieces of software. I'm not counting the things I use implicitly, like web servers or GTK - I'm just talking about the pieces of code with which I consciously interact. Here's a sampling:
- Yaourt (archlinux package manager)
- The collective of unix shell utilities
- Firefox, +addons
- Thunderbird, +addons
- Google Apps (Search, News, Youtube)
- Hacker News
- Pandora
- VirtualBox
- ssh
Take note, first, of how broad some of these items are. "The collective of unix shell utilities" includes coreutils (itself a large set), vim, make, jam, the Go tool-chain, the Haskell tool-chain and the C tool-chain. All the addons I use with firefox: one group.
If, and only if, you're writing a "first-tier" app - something that has a realistic chance of making it on a list like this one - you should compare your overhead requirements to what you might expect from these. Would you watch a 30-minute video tutorial to learn how to use Reddit? No? Then don't make it necessary to watch one for your own product. (That's not to say you shouldn't make a 30-minute video tutorial - but you should assume that nobody will watch it, and design your app accordingly.)
But you're not writing a first-tier app. Notice that instant messaging and video chat didn't make this list. Are you cooler than the ability to talk face-to-face with someone halfway across the world in real-time? No? Then I don't want to waste 40 seconds reading a "how-to" before I can even start using your product productively. I have other, better things to do. Like checking out your competitors.
What you're creating holds no special place in anyone's heart. Even veteran users will happily drop you if you add too much overhead (think Firefox circa version 4). You'd do best to make yourself invisible, but necessary. Software should be used, but not heard from.
By the way: this principle applies just as strongly, if not more so, to software made for developers. While it's true that we have a fabulously high tolerance for pain when first setting things up (because we know that with that pain we buy power), that tolerance is exchanged for roughly zero tolerance for overhead later in the adoption cycle.
I was inspired to write this rant by Go's recent switch from make-centri build to a specialized tool. The "go tool", as it is called, purports to handle all project configuration and build problems automatically, eliminating the need for the tedious creation of makefiles. What rot. Aside from the various technical benefits makefiles provide over the go tool (among them the ability to easily auto-generate source code when necessary, and in general to express arbitrarily complex dependencies), makefiles are easier to use by the simple virtue of being universal. I don't only program in go: I use javascript, haskell, python, lisp, go, and C all on a daily basis - and sometimes in the same project. I don't want a separate build tool for each, any more than I would want to have to use a separate editor for each. I like being able to type "make" without giving it a second thought, and know that whatever I was creating before, is now being compiled. No context switch - no mental overhead of figure out what tool to use - is necessary. You can make my life easier by auto-generating the makefile, or by providing a nice configuration for my editor, but please don't try to replace them. Your language is but one of many. You're not special.
(In fact, most of my projects that are built in languages using a specialized build tool - go, haskell, etc... - have a simple makefile wrapping that build tool, sometimes in ugly ways. Just because it's easier.)
