My skills go back to the age of teletypes, so perhaps I'm atypical. I use CLI's a lot in everything I do because they are often a lever that lifts things impossible with the GUI. But GUI's are also levers for moving things that are impossible to move easily with a CLI. Despite the fact that Cisco's IOS CLI is touted as a powerful interface, it's all too often inconsistent, and poorly realized. There is an art to writing a good CLI, and Cisco lacks artists of talent these days. GUI design is an art as well, and we all can cite examples of poor design.
However, I'd like to point out a related negative trend regarding GUIs. I've observed that systems designed around GUIs often reduce our ability to audit change. The mindset that comes with designing GUIs often forgets our need to compare what is now with what things were the day before. This trend leads to less logical and more instinctive, and often irrational troubleshooting.
Whether GUI or CLI, if configuration state is properly designed, and provisions for auditing are built in, the customer and vendor benefit from less noise, less religious strife in user forums, and more reliability. What we often get are hastily implemented features that indicate lack of design discipline and philosophy on the part of vendors. The user view of a check box implies that an object lies beneath. In actuality, there's often many objects and conditional rules. So unchecking a box sometimes does not roll the change back as expected. In a CLI, a single command implies a similar model. Adding "no" or "disable" before the command implies a similar rollback that sometimes is not there. I've wasted literal years of my life troubleshooting installs and config changes that violate these basic assumptions.
So whether CLI or GUI, the things I want are:
1. Auditability of the configuration itself
2. History of changes
3. Control logic that makes a change can also undo the change properly.
This is QA and CM 101 level stuff. The auditability and history makes it easier to do this QA and CM (Quality Assurance and Configuration Management) much easier. Failure to do this is a software engineering management failure often caused by marketing pressure for time to market. Salesmen, listen to me - if you can advertise basic auditability and consistent interface design by meeting these 3 requirements (auditability, history, and control logic), your market share will go up. The old joke about "job security" should not be an accepted truth.
Look at what ASDM and SDM do to the readability of config files. Look at how bloated the Windows registry is. Install almost anything, uninstall it, and see how much is left behind. Look at how much resistance there is to upgrades because of changes to GUIs because they were poorly designed in the 1st place, poorly explained in documentation (within the GUI itself!0, and features were added as afterthoughts.
We shouldn't have to crawl into the sewer to fix a leaky faucet.
