Designing command-line interfaces

I like the posting Designing command-line interfaces. Being a CLI type developer I have implemented most CLIs with Anders' recommendations in my tools. Points I would like to emphases are

1) For long running commands make them verbose by default. For short running commands, like mv and cp, make them quiet by default.

2) While I like autoconf's use of "no" to turn off an option, eg --no-foos, and "=" to provide an option's optional value, eg --debug on default port or --debug=port for a specific port, it is not used enough elsewhere and so is too unexpected. Don't use them.

3) Always use a non-zero exit if you find an unknown option or an unknown positional parameter.

4) Use one-dash for one-letter options and two-dashes for multiple-letter options. Eg, -v and --version, -h and --help. There are many libraries available that help parse options. I tend to only use two-dash options and so hand code the parsing.

5) If you don't use one-dash options make sure to reject all positional parameters that start with a dash as this is mostly a user error. If you want to allow positional parameters that start with a dash then use the common "--" parameter to indicate that the remaining parameters are all positional parameters.

6) An option can have multiple arguments. For example, --database url user password.

7) Always have the options --help/-h, --version/-v, --quiet/-q, and --verbose.

8) If a command can run without options make sure the command's results are harmless. Nothing worse than incorrectly using a command and having it destroy data.

I will, perhaps, add other points for emphases at a later date. For now, do read Anders' posting.

FYI: Kanban for Software Development

The posting Kanban for Software Development is one of the clearest introductory explanations of kanban that I have read. For example,
This is where the somewhat brilliant key idea behind KSDM comes to play. The completed job does NOT free the person for working on another job, until that job is pulled into the following phase and work is started there. If work is piling up at a particular phase, those people are NOT ALLOWED to work ahead. As Taiichi Ohno makes so clear, that working ahead is waste. Instead of working ahead, they can look around to see what is wrong.

To put this in concrete terms, consider a process which involves (1) detailed design, (2) coding, (3) testing, and (4) documenting. Each of these stages you place a limit on the number of jobs, and for the sake of example lets say that limit is 4. Say for example that the coders have finished coding on their four job units, and are ready to take a new one. But the testing is backed up for some reason, still working on the last four job units, and are not ready to take a new job. The developers are not allowed to pull in a fifth job unit. There is no point in coding up more features when the earlier features are not getting tested or documented. It is also possible that because the developers are not pulling jobs from design, that the design phase becomes filled up with completed tasks.

When work backs up in this way, one should go and figure out why testing is stuck. Maybe the real problem is that the documentation is blocking test. Whatever it is, the primary job of the entire team is to identify the problem with the flow, and fix it. Do not simply work ahead accumulating a huge pile of work for “someone else”. Instead, focus on the big goal, which is to get features completed to a customer ready state as quickly as possible.

The Problem with Kanban

Comment on The Problem with Kanban | Javalobby:
The biggest problem with Kanban is that it‘s designed for a world where things go through the line once (e.g. a carmaker).
This got me thinking about whether the problem is generally with Kanban's use in software or instead the kinds of software development Kanban that is more useful in. A service firm builds a single use or single customer tool while a product firm builds a multiple use or multiple customer tool. A service firm tends to have more tasks around the missing parts of the software while a product firm tends to more tasks around the bugs in the software. For a service firm the factory is the assembling of the parts. For a product firm the factory is perfecting the assembly. I am mostly thinking aloud here but I think it is a useful train of thought as to why Kanban works for some firms better than for others.

Long Now seminars

The whole Long Now seminar series is very good. If you have iTunes and an iPod just add their pod cast to your iTunes library. Note that the lecture's audio is free but video requires membership. Here are specific lectures I keep coming back to

Mary Catherine Bateson
Live Longer, Think Longer

Jesse Schell
Visions of the Gamepocalypse

Geoffrey West

"What's with the moribund twitter bio?"

Eliel asked "What's with the moribund twitter bio?" I am thinking that it must have been a "can't get anything right" kind of a day when I wrote that. But in all honesty, I am not a natural father and so find myself consciously working at it everyday and the same for marriage (perhaps every other day here). And, how many times have I been granted but never exercised stock options? I am a very optimistic guy. While everyone else (ok, many) are grasping for success I am happy working at being a little more whole one day at a time.

Keeping power and maximizing shareholder value

In the 1970s our US government representatives stopped caring about their constituents and started caring only about keeping their own job and its access to power. The corporations didn't initiate this change. They are, however, proficient at using the change. Corporations are just doing what corporations always have done and that is to maximize shareholder value by aiding representatives to keep their jobs. I hate to deliver bad news but y'all are the shareholders -- via pensions and other retirement vehicles -- and so are benefiting.

If you want to help take away the power of money in politics then support (Lawrence Lessig’s) Fix Congress First.