Recently I have been in charge of building our product's CLI (command line interface). It is a low profile project because the management team of our company put their focus on our super-cool-super-easy-to-use-and-fun GUI (our CEO wants it to be the iPhone of enterprise software). The lack of attention turns out to be a good thing, because the user-interaction focused approach may actually be a very bad thing for the CLI (after all, a CLI is run most of the time by the machine through scripting, not human interaction). It also gives me a freer hand at negotiating features and choosing the technologies used. I thoroughly enjoyed building it.
Yesterday we did a first end-to-end integration demo of our product using the CLI. Since we only finished integration two hours before the demo, I was quite nervous and worried if we would run into issues during the demo. I didn't focus much on the CLI (that was not the purpose of the demo anyway). Only after I was done with the demo I realized I forgot to mention some of the "cool" features. For example, a general problem with CLI is there are too many options, so I add a "history" feature to record the user typed commands to a file. The file can later be executed by the CLI so it will save the typing (and becomes very handy for cron jobs.) Things like this are small, but they can be combined to make the CLI a very useful tool.
I remembered an interesting conversation with an ex-coworker. (I was trying to recruit him to our company to no avail.) We were talking about software design. He said if you planned to design a perfect system (or language) which did everything, most likely it would fail (anybody still remember Ada), but if you focused on some design principals such as simplicity and adapability, you might build a system that lasted longer than the "big-bang" solutions (he used the UNIX system as an example.) Looking back at the CLI design choice I made, I realized that it might not be an iPhone, but it might well be a Swiss Army Knife!
No comments:
Post a Comment