A few times over the past several weeks I've been reminded of how difficult it must be for vendors to maintain consistency in administrative or user interfaces while expanding the capabilities of the product, and how painful inconsistencies can be to those of us who use those products. Some companies have major problems with this and alienate users by moving too quickly or without sufficient notice or documentation, while other companies handle these situations with aplomb, at least some of the time.
Of course we might look at Apple in the consumer space as an example of a company that gets it right. It's remarkable how Apple has maintained consistency across versions of Mac OS X and iOS through 15 and eight years of existence, respectively, while also enhancing and improving both products substantially.
We might look at Microsoft as a mixed bag of successes and failures. Certainly, maintaining the core of the Windows 95 UI straight through to Windows 7 was something of an accomplishment, but the user interface issues that drowned Windows 8 serves as a harsh contrast.
In truth, interfaces are difficult to design and difficult to maintain over time -- really difficult in some cases -- and that translates all the way down to the command line. In fact, changes in a CLI can be downright dangerous.
The largest network vendor in the world, Cisco, is still holding on to IOS (not to be confused with Apple's iOS), which is the core of its routing and switching lines. In fact, some might recall that Cisco's big switches used to run CatOS and a hybrid with IOS for Layer 3 tasks. That was long ago, and now we have a consistent platform across a large number of Cisco switching and routing devices. Cisco ASAs run something that looks and feels quite like IOS (but in fact isn't -- there are some marked differences), though the ancestry of the ASAs does not start with Cisco.
Regardless, the fundamentals of IOS trace back several decades now, and the interface itself hasn't changed all that much. The configuration and privilege modes, the syntax, and the basic functionality are all essentially the same whether you're working on a 6509 in 2003 or a 6509 today.
You might consider VSS (Virtual Switching System), the newer technology that allows bigger switches with newer supervisor engines to operate as a single entity. Rather than connecting multiple cores in a redundant configuration with HSRP and STP configurations, VSS allows the switches to operate as one. This means combining the configurations seamlessly. Where you used to log into switch A and reference GigabitEthernet2/2, say, you now reference GigabitEthernet1/2/2. GigabitEthernet2/2/2 is Switch B, and so on. This enables several new features, such as multichassis EtherChannel, stateful chassis fail-over, higher overall bandwidth capacity and load balancing, and more -- yet from an administration perspective, it essentially drives like it always has.
This includes lower-level functions too. I recently stood up a pair of 6509s with VSS and gingerly tested a relatively complex custom administration app that provides a captive portal for unassigned ports and uses SNMP to dynamically locate the port a user is connected to and reassign the VLAN as needed. The code required no changes to work with the VSS pair; all of the SNMP interaction Just Worked. That's the kind of thing that admins really, really appreciate. Now, you might say that maintaining the MIB in that way was incumbent upon Cisco -- I'd agree -- but it was still very nice to see.
On the other hand, Cisco has a habit of changing the CLI in other products, such as the ASA security appliances. In the past decade or so, the company has changed the NAT configuration syntax completely three times, in addition to other minor (but annoying) changes that catch you up every time, especially when you work on multiple systems running slightly different versions. Ask a security admin about the ASA version 8.3 and 8.4 history if you want some salty language. Heck, in that upgrade Cisco even killed the default log-in (pix@<ipaddress>) without warning.
If you weren't aware of this change and you remotely upgraded a unit that was using the default login (which is a lot of units), you wouldn't be able to log back in after the upgrade without physically connecting to the console. Yeah, that bit more than a few folks.
As challenging as maintaining consistency might be, it's extremely important, especially in fundamental products such as server and network operating systems. Adapt or die, indeed, but don't change too much while you're at it.