Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.

Larry Wall, creator of Perl

Aside from rockin’ an awesome ‘stache, I have a good level of respect for Perl’s first author. The language he created is totally pragmatic and probably holds the Internet together. (Aside: if you’ve ever looked at the Debian installation process, you may have noticed that Perl is used at an incredibly early stage and does some serious lifting. I think that’s really cool.)

Larry’s mindset about laziness motivates me to focus intently on the tool’s that I make. A good tool makes it look like everything is easy and you’re being lazy by using them. So, for command line tools, I have some rules of thumb:

1. The optional flags had better be optional. Seriously. I’ve had to work on projects where the amount of flags passed into the tool rivaled the complexity of an airplane cockpit’s dashboard. You won’t win any friends by making a monster interface. If your tool is complex, you can manage it by following the convention in the industry of using sub-commands (e.g., git, svn, pip, apt-get).
2. Configuration files are your friends. Users should have some choice about how to instruct your tool to do work. When the only option is parameters on the command line, you force them to recall old commands from their history or remember all the ordering and flag names that you built into your system. By providing configuration file support, users can capture their needs in a file instead of their wetware, and they’ll have an easier time using your product.
3. Avoid jargon. Many people in your own field probably despise some of the jargon that is used in professional communication. For the software world, I am such a person. I’ve met developers that love to use jargon. Maybe it makes them feel important and intelligent, but when what they say feels roughly like talking about a “complex for stationary automobiles” instead of a “parking garage,” I can tell they are full of crap. If a user has to translate from your babble into something comprehensible by a “normal” human being, then you lose.
4. Provide good help. Ideally, the help documentation for your tool should be as close as possible for a user to access (e.g., foobar -h, foobar --help, foobar help). If you don’t keep the help docs close to the implementation, you run the risk of getting out of sync. Additionally, documentation should also be accessible from more than just the Internet. I work in an industry that frequently uses private networks that don’t have direct access to the Internet. Without local docs, learning about a product can become a harder task. Lower the barrier of entry for your users whenever possible.

If you factor in some of these tips, you’ll let your users be truly lazy. Your tool will be easier to understand, there will be less for them to remember, and getting the right information would be simple. With an easier tool, users can be lazy and focus on more important things, like grooming an amazing mustache.