10 Dos and Don'ts To Make Sysadmins' Lives Easier

CowboyRobot writes "Tom Limoncelli has a piece in 'Queue' summarizing the Computer-Human Interaction for Management of Information Technology's list of how to make software that is easy to install, maintain, and upgrade. FTA: '#2. DON'T make the administrative interface a GUI. System administrators need a command-line tool for constructing repeatable processes. Procedures are best documented by providing commands that we can copy and paste from the procedure document to the command line.'"

Comments

click-wall.

[nblender]

Don't make me use a real browser to click all the way through your site, make me agree to a stupid set of conditions for using the software, and then provide my browser with a cookie that it can subsequently use to download your software; when my browser is on one continent and the machine that wants the software is on another continent; you ass-fucks...

That's plain ASCII to you...

[sl149q]

> DO have a configuration file that is an ASCII file, not a binary blob.

And by ASCII we mean something that can be edited by any editor.

XML is the equivalent of a binary blob when you are up to your ass in alligators trying to get things working again with minimal tools available.

Re:#11: Meaningful error messages

[Monkeedude1212]

That reminds me of a Web Developer I once knew.

He said he didn't bother putting try/catches around certain standard things (Like Database connection opening, closing, transactions, etc) - because if anything ever went wrong it was easier for the user to take a screenshot of the Stack Trace if and when it went wrong from the Webapp. Said it took too much time to build in proper exception handling and error messages.

He said that the user experience basically means nothing if your application doesn't work, so when something doesn't work, don't bother making it pretty.

He no longer works here, though I can't imagine why.

Amendment to #2

[c 0xFF]

Feel free to make a GUI for the administrative interface, but not at the expense of an underlying CLI.

There are two ways to do this: have your GUI call the CLI when necessary, or use a common API behind both. Other methods will lead to bitrot in one of the interfaces, most likely the CLI.

GUIs are fine and even enjoyable to a certain extent, but the author is right that the CLI takes priority.

Re:I disagree on the GUI

[Qhartb]

I think it's more a matter of not making a GUI instead of a command line interface. Making both is, of course, perfectly fine, so long as the CLI is fully-featured and reasonably usable.

Eventlogs

[Spad]

In reference to point 8, this is something I wrote I while ago after dealing with several Windows apps that either horribly abused the Eventlog or refused to use it entirely:

• DO create your own event message DLL(s) where appropriate to avoid your events looking like this
• DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.
• DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0×8003387 means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.
• DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.
• DO make your logging level easily configurable by the user and DO set a sensible default.
• DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.

#1 big dont

[MrLint]

Do not assume that your software is running with elevated access... (root/administrator)

Re:1 Do for being a user

[jombeewoof]

I disagree,

take any person of reasonable intelligence and place them in an unfamiliar settting. They become retarded.
The fact that they have been in front of that unfamiliar device for 20 years means they just don't care.

Give me a user who cares to familiarize them-self with the system and 6 months, I'll give you a half decent sysadmin. At least better than half of the paper certified MCSE's I've had the pleasure to work with.