The other day a recruiter asked me if I built CLIs (Command Line Tools) often. To which I honestly answered that no, I prefer to build UI based tools, as I have found them to work better for engineers. These should live in internal tooling webpages, where they can be protected on corporate networks requiring corporate VPNs to access.
As we are building more and more visualisation tools, and our systems become more and more complex, why do we hang onto the idea that we need CLIs for operations and low level stuff. However when someone tries to build an UI instead, they are made fun of. As a stubborn person I build it anyway, and then see just how much more accessible it is after the fact. So why do we have such an attitude towards CLIs as being superior? And if you are already using websites to read data, why not use them to rewrite it?
The primary reason I've found myself using CLIs is to fix things that are broken. Primarily during my oncall. A lot of these scripts have been proven useful in a mitigation of some breakage. However, that is all well and good during the work day when you already are at your company laptop, already have the script handy.
Let's pose the problem of the type of breakage that wakes you up in the morning. In an UI, your phone rings, you see the type of problem it is, go to the appropriate UI and then navigate with a few buttons and run the remediation you need. If it's anything more complicated than that you would have to write code and properly wake up anyway, in which case someone in a different timezone who is awake will be more capable to resolve the problem anyway. And if they don't it can wait until you are fully awake. With a CLI, taking into account the time to go get your laptop, type in your secure password, log in to VPN and all the other steps you need to take to just get to the secure terminal means at least 20 minutes until you can even start considering what to do. (maybe that's an exaggeration to you, but that has been my average response time from being paged to reaching a state where I could insert the right commands)
CLIs are the trademark of someone who knows what they are doing. Piping multiple scripts together to do things over and over again, when no-one else knows what to do. When often a lot of these complex scripts are somewhere in your command history, and you just change some params around.
Now let's take a person who is new on the team and needs to do all these things too. One option is to feed them all these scripts you've saved in your bashrc and the few which you just have in your command history. But I've found people often forget about them. So when the time comes to need them for the first time, you can't do anything other than ask the more senior person. Why not just go here's a page with all the tools our team built and uses. Done. Onboarded.
But let's also look at the level of competency this new person would need to have. As Operating Systems are becoming more and more UI centric, CLIs become less of a necessary skill to have. Like complaining that a 16 year old kid cannot operate a rotary phone... well, they don't really need to. So CLIs become restrictive in the types of people who can use them. And it's not only about hiring, but also about enabling other teams to unblock themselves, easily. But with a CLI they can't, as they are often too complicated for anyone other than your team within the company to do, because only the team who routinely use them have enough context.
I've seen tech get so complicated people needed scripts and UIs to figure out which command to run. As systems scale the tools to deal with them become increasingly more complex. As a result the CLIs for them grow. I've seen these go one of two ways: Either the number of arguments increases so much you have to have another script automatically generate the arguments for you. Then you copy paste the script it gives you and continue. Or you have an exponential increase of scripts and you need to remember which one does which, and your average command it three scripts piped together. At the same the manual gets so big you just couldn't read it all every time you need to do something. It comes to a point where the options you want to pass in become large enums that a dropdown menu would be invaluable to make sure you got it right.
One cannot overestimate the importance of just having a link to a tool. This can be present in the company directory and be bookmarked on the default setups of the company. Most of us have UIs with the graphs and alerts of the system health. Wouldn't it be grand that in the same place you notice there is a problem... you could fix it?
Have you ever tried to display a graph in the terminal? It is technically possible... technically...
Especially in the context of operations but not limited to, I have often found that additional context is required to make the right decision. So we go full hacker mode with 5 screens each holding different information that is required to know which command to fill in next... one of which holds the documentation of the command. I have seen people who have spend weeks in trying to use a graphical interface in their CLI to show them the graph that will tell them which path to take... to which I can only say... why? But then I could print a lot of text that gives me all the information I wanted... and who will read it?
All while a UI could do all this more visibly, and likely in a lot less time... And if that doesn't make you look cool enough... we can make sure we download a terminal skin for your browser and use css that gives the tool a terminal look. Just so it looks like you know what you are doing.
The only real reason I could see why CLIs would be more valuable in the event of an emergency, is that they do have fewer dependencies. However if you write your code in a modular fashion, so that you can just call the functions when when the webservers are down. Ultimately, well written UIs should not be slow, and in a time of emergency we need something simple and visual to make sure it catches us out on our mistakes.