Wow. For once I’m not the crazy one! My dear friend and colleague Jason wrote... well... an interesting take on the validity of a command line in the era of the cloud. If you missed it, take a moment and read it over. I’ll sharpen my pitchfork while I wait.
Good? I told you it was interesting. Now I’m all for pressing forward with modernization of both tools and control surfaces, and I’ve long believed that IT is last to the party with good UI design, but I am not even close to being ready to put any nails in the command line’s coffin. Let’s look at his arguments.
1. It’s prone to syntax and spelling errors
2. It’s antiquated
3. The developer should reveal all internal error-control in the GUI
4. Every possible command should be visible in the GUI
5. Don’t force scheduling or automation on me
I hope it’s clear before we even start that I’m a proponent of the command line. Even outside these arguments, interacting with the command line has taught me one of the most valuable lessons of IT: sometimes the query you want is actually the inverse of the query that’s possible. I.e., sometimes you have to actually understand the limitations of the product to use it successfully. Trying to trudge through those limitations in the GUI is an exercise in futility. “Why can’t I just...” is the beginning of most questions I hear from my GUI-based brethren. Understanding those limitations over time also helps the grizzled admin understand why some code works, and some just doesn’t. Call it institutional knowledge or job security: knowing where the product has come is always helpful in understanding how to deal with a problem at hand.
And weirdly, I see it as a declaration of a product’s maturity and staying power when a CLI is published. I’m sure that seems backward, but here lately the command line is the after-thought in cloud development.
But anyway, on to the arguments...
I can’t even begin to claim that I’ve never had an “oh crap” moment at the command line. I’m pretty sure I took a cluster server offline for about 3 hours for 3000 users a few years ago. AWS had a widely-publicized oopsie a while back that dropped storage nodes and resulted in a widespread outage of S3. That oopsie was also generated at the command line. But the interface doesn’t deserve a pink slip for transgressions of the operator. I’ve written hundreds of scripts, both within VB and PowerShell, and done a bunch of macro work. Before I commit anything, I work with queries. “Get-“ is always safer than “set-“, and “-whatif” is generally available to prevent catastrophe, if you’re patient enough to use it.
And that’s really the trick: using the tools that are available. A good and sensible admin, responsible for many systems and production users, does not just blast out commands willy-nilly. Every time I’ve scripted something, it’s begun with section-by-section testing. Am I able to query this attribute? Can I feed it to this other command? Does that query generate un-due load on the servers? I’m sure most of us aren’t writing much VBS these days, but I can’t remember the time I didn’t start a script without “OPTION EXPLICIT” and “ON ERROR RESUME NEXT.” I don’t want hung scripts pegging my servers all night, or going off the rails when an attribute returns an unexpected value. Oh, and I test the ever-loving heck out of my stuff before I schedule it.
But the GUI? There’s no “what if” in most UI’s. Just ask the poor guy who told Hawaii they were under imminent missile attack. Now you can argue to your heart’s content that Jason’s point holds: the missile warning system had a terrible UI. But until the company paying the developer is willing to invest real effort into control surfaces that will only be used by very limited groups of highly-specialized users, I might prefer that we just put 2 icons on the missile warning system’s desktop: “Alert FOR REALS YO” and “TEST ALERT.” Both could just run scripts, and we could put like 50 pauses and interstitial warnings in the “FOR REALS YO” script to make sure it doesn’t get blasted out for actual really reals.
It's antiquated? By what measure? We’re still running Active Directory, and that’s old enough to vote. Next year it’ll be old enough to buy alcohol. The CLI has persisted because it works. Automation is possible because of it, and automation is the name of the game in environments with any measure of complexity.
Arguments 3 and 4 I’m gonna tackle as one, and it might seem a stretch, so bear with me.
One of the fundamental principles of good UI is to enable the user’s productivity. To that end, the average new user of any product probably isn’t going to go down the deepest of rabbit-holes looking for esoteric commands and rarely-used functions. They may ultimately use them, but presenting those right off the bat can be counter-productive.
I’ve probably talked about it before, but years ago a team of researchers set up a free cheese display in a grocery store. They were trying to figure out the mental mechanics of decision making, and they tested over several days. On some days, their table had 24 different cheese options that anybody could sample for free. On other days, only 6 options. What they found was that, when presented with 24 possible choices, most folks picked nothing at all. With only 6 options, they certainly didn’t give cheese to everybody, but there was a substantial uptick in sampling.
I’ve always seen that as a real-world example of the power of the 80/20 rule: 80% of the people probably only need about 20% of the functionality of any given tool, and may well be turned off from using a tool that proudly displays that additional 80% of commands. And if users are overwhelmed by extraneous commands, I guarantee they’ll be put off by a fusillade of warnings and error-control messages.
So we limit the UI. We cut it down to what a novice user could expect to use in day-to-day operations, with the option to reveal some additional functionality for the more advanced user. But we put the real meat in the CLI, because there will be that 5 – 10 % of users who really need the tough stuff, and my guess is those folks are ready, willing, and able to open a support ticket with the manufacturer to get to that code.
As for not compelling automation? I can’t force you to be efficient. That’s on you.
By: Adrian Amos