I did a round 1 several years ago, and I can’t remember when round 2 happened, so I played it safe by calling this round 3.  Anyhow, the point of this is what exactly?


The point is, I’m an emphatic proponent of anti-dogma.  It started as a child, when others would say to me “G.I. Joe cannot really fly.” and I set out to prove them wrong.  Then they said “Plastic model battleships can’t really do battle or explode and sink” and again, I proved them wrong (and a big thanks to the local fire department for helping to bring that sea battle to a safe close).

I just had my first cup of real coffee in 48 hours.  I can’t explain why.  I think I was having some sort of self-hatred phase or something.  So, I’m having what Leonard, in the movie Awakenings, would call a “moment of clarity”.  Or, maybe that was Jules in Pulp Fiction, anyhow…

In this case, it’s the dogma that CLI is inherently better than GUI.  It’s the same argument that one programming language is “the best”.  Or that only one kind of food is objectively “the best”.  To me that’s saying one tool in the entire hardware store is “the best”.  Being yet another kind of tool, as I’m often called, a CLI or GUI is “best” with regards to the context.

For scalable repetition, CLI is often the obvious choice.  And for single-instance scenarios, a GUI is often ideal.  But there’s that big middle ground, where the Red Bull drinkers debate the Supplement powder drinkers for world domination of the “my way is the only way” argument.  Those are indeed first world dilemmas.

First off, let’s keep things in perspective.  Just as the early-mid 1960’s were rife with the phrase, “it’s a man’s world“, and don’t hate me, I’m just offering an observation from watching Mad Men; 2017 is still a GUI world.  You can argue this if you want, but if CLI were truly the king of all that is software, you would NEVER see a packaged application installer with a GUI face, and your “smartphone” would only be a command prompt, and nothing more.  Touchscreens, video games, music production software, credit card swipers, ATMs, airline ticket kiosks, all are immersed in the GUI bathtub.

That said, CLI is obviously the king of process automation.  The efficiency comes in with zero-interaction operations.  Pre-configured parameters.  Even when a GUI is optimal for a given task, the trend today is to equip the GUI to save parameters to a file in order to leverage that captured parameter state for CLI repetition.

As one friend of mine would say “if you’re pulling one engine, you rent a hoist, and buy a case of beer.  If you’re pulling 1,000 engines, you get a loan and build an assembly line.

Let’s break the GUI down a bit.  One of the common points of debate is around item selection:  Radio buttons, check boxes, single and multi- select lists, dials, sliders, date pickers, range approximation, color pickers, and so on.

Much of the following is derived from a project I worked on back in college.  We were discussing the merits of CLI vs GUI and our professor said “prove it.  with numbers.”  So we consumed sufficient quantities of caffeine and sugar, and went to work.

If you use a stop watch, and compare two engineers, equally caffeinated and infused with sugary snacks, and have them execute the same tasks in both the GUI and CLI, excluding differences in relative typing speed/accuracy, or mouse control skills, the completion times will lean towards one or the other based on the circumstances:

Disclaimer: This is based on a “first run” scenario, where no preconfigured data is yet available or determined.

  • Check boxes.  If using “Select All” or “Select None” the difference is zero.  But sporadic, non-contiguous selections, are quicker by GUI clicks than by typing in non-contiguous names.  This is further differentiated by the relevance of string pattern consistency.  If RegEx or wildcards can be used, it can lean in the favor of CLI.  But if the selections provide no consistent patterns, the GUI will win hands down.
  • Radio buttons are a wash
  • Single-select lists are a wash if the list does not require scrolling in the GUI.  If the list requires scrolling, the CLI is faster.
  • Multi-select lists are only marginally quicker by GUI due to CLI having tab-completion.  This is predicated on a static set of options to select, which can be fed into an IntelliSense cache.
  • Sliders are faster via CLI (direct input)
  • Date selection is faster via CLI (direct input)
  • Calendar pickers are faster by CLI (direct input)
  • Color pickers will vary by pre-determined color values.  If you don’t know the color, but you are selecting by visual acuity only, the GUI is faster.  If you know the color name or code value, the CLI is faster.

The caveat from here on out is that once the GUI is used, if the inputs are captured, then the CLI steps in and knocks it out of the park.  This goes back to the repetition claim.

So, what does this really mean?  Aside from turning capable IT professionals into non-productive windbags (until the boss walks in), it means that anyone writing software that uses a GUI, and expects their product to be used repeatedly, should be building in a means to capture inputs to a file to facilitate reuse via CLI.  If they are not doing this, they can only fall into one of the following categories:

  • They’re stupid or lazy, or both
  • They don’t really care about customer satisfaction
  • They need to be beaten with a pepper spray can and tasered until the battery runs out

Until next time: happy CLI-ing.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s