Banazîr the Jedi Hobbit (banazir) wrote,
Banazîr the Jedi Hobbit
banazir

  • Mood:
  • Music:

The User-Centric Manifesto

Systems administrators and users often don't see eye-to-eye on priorities and policy. Having been a lab proctor, a sysop, a sysadmin, and a user before at various different times, I thought I would take a crack at expressing some of these differences from the user's point of view.


Preamble

Now, there are a couple interesting things about user advocacy, and I'd like to take a moment and outline them before I move on to my specific points.

The first is that while there are a lot of advocates for less competent users ("lusers" in the vernacular), I will assert that there are fewer advocates for competent users. This is partly because the meritocratic, sometimes technocratic (or at least technically chauvinistic) culture of computing insinuates that a competent user needs no advocate: he or she can either do it by himself or herself, is part of the systems administration team already, or is well-qualified to school whoever comes along in how to do things right. The problem with this outlook is that it leaves some competent users quite disenfranchised: namely, those who lack not the inclination but the time and resources to do it ourselves, who aren't part of the sysadmin organization (even in an honorary capacity), and who may know a little about the hardware, OS, package, or service at issue, but aren't such experts that we don't need help and some user education from qualified admins.

The second thing is that because most sysadmins are also users, it really isn't that difficult to see things from a competent user's POV. The catch here is that a sysadmin being asked to help with X is probably considerably smarter than the average bear when it comes to matters of X. A user may be competent, but the sysadmin's perspective may yet be as ineffable as the cosmos, for the simple reason that the sysadmin has specialized knowledge that comes from privileged sources: tutorials and training courses on the hardware, OS, package, or service; hands-on experience; and above all, access to a working version.

So, competence is as competence does. The purpose of this short essay is to encourage our sysadmins, and anyone else reading this, to try to think more in terms of user productivity. When I was a lab proctor, I would often play the following game: how much user time can be saved by my helping out with this, and how much of my time will it cost? As a result, I often stayed an hour to help five users save a total of five to fifty hours. Was it worth it? Perhaps sometimes; probably not always: there is definitely a lot to be said about "teaching people to fish". When it all comes down to it, though, competence is paid forward. Help someone today and he or she is a helluva lot more likely to help someone tomorrow. I know that was the case with me: it's how I became a lab proctor at the end of my first undergraduate year in the first place.

I will now address a few specific points along these lines. Your opinions, critiques, and other feedback are welcome, with one proviso: if you think I've got it all wrong, or you feel I've hit it spot on, feel free to say so - but tell me why. Back up your opinions with experiences and rationale. And above all: remember what it's like to be a user, even if you are also a sysadmin.

Manifesto

  • 1. It only takes one. "You are the only one" (i.e., the only one with this problem, configuration, way of doing things, etc.) is a common phrase used to absolve systems administrators of responsibility for a problem. Think about it, though: it really takes only one reproducible or intermittent error report to make a potential issue. As long as the error is persistent and high in negative utility - that is, as long as it is costing some user valuable time - it is worth looking into. Now, sysadmin time is valuable, and so is user time; I'm not weighing any one sysadmin's or user's time in relation to anyone else's. Rather, I am saying that it doesn't always come down to headcount. Perhaps the user is an early adopter and the "advance problem" is a harbinger of later problems to come. Perhaps the user is a legacy user but is representative of many more who will be left behind when similar packages or services are retired. Or perhaps the user does things just a little differently in a way that nobody else currently in the lab or office has seen. In each of these cases, there are often very good reasons for considering a problem worth isolating, and fixing it as time permits.

  • 2. User education is a right, not a privilege. As I said, competence is paid forward. In other words, we reap what we sow. I could delve further into biblical proverbs or Aesop's fables of favors returned, but without getting any more hyperbolic than I need to: generosity reinforces like behavior and encourages the beneficiary to share. More specifically, teaching a person to fish increases the likelihood that he or she will not only give someone else a fish in the near future, but that he or she will teach someone else to fish in the farther future. As a concrete example, the Undergraduate Computing Facility (UCF) at Johns Hopkins was one of the busiest and most well-utilized labs on campus. All we had was a dozen Mac SEs, a Laserwriter, and a Mac II (later, a half dozen PS/2s and a half-dozen Ultrix systems). A single undergrad sat near the door drinking soda. Years later a couch was added. It was no different than thousands of campus labs across the world. But people came. People were helped. People signed in saying "I hate computers; typewriters are so much better" and left knowing how to do basic things in Microsoft Excel and GNU emacs. Sometimes the second through fourth-year undergrads would tutor their juniors in Lightspeed C and Scheme programming. Sound quaint? You bet it is. Today, I see esprit de corps at an all-time low. We record 100-level service courses on CDs and on Tegrity and we give undergraduate students course credit for learning how to use Word and write small utility programs in Visual Basic. These are not bad things in and of themselves, but they illustrate an endemic problem: people are less and less interested in learning the technical skill of computing (not the science, not even the engineering fundamentals) through experience and interaction, and more interested in acquiring technical certifications through passive learning. Learned helplessness is rampant. I'm going to go out on a limb and say that a significant part of this is due to decreased willingness on the part of once-eager tutors. Perhaps they were disillusioned, but going back to my point: help breeds help; apathy, more of the same. Five or ten generations of users down the road, you get CS graduate students who arrive on campus never having used FTP. (You think I'm kidding? I wish I were.)

  • 3. Opportunity cost matters. That is, potential net productivity loss is a better measure than net utility gain. This goes back to my first point: when we think about whether supporting a soon-to-be-obsolete package is worth while, or a user service that is about to be taken over by another administrative unit, we need to also consider how many problems will crop up if we don't look into reported errors. Will the next retirement of legacy software be as smooth or will the inconvenience level ratchet up? Will the transition still be smooth if we ignore the problem, or is it worth a little of our time to check it out in advance? My rhetorical questions imply that it is worth while, but this is not always the case; I am only saying that the value of a software fix is the sum total of immediate payoff and saved time in the long run. Additionally, the Horde of Irate Users is an irritating thing to deal with once the old system is scuttled or control of mail, news, web, or other services is handed over. Those of you who have dealt with users unreasonably asking for file restores after scratch volume /tobenuked is purged after half a dozen warnings know that users who have a legitimate complaint about unexpected software failures can be umpteen quijillion times more vociferous. Now, you may be saying, "why, that's all well and good, but like caching and virtual memory, it's infeasible to predict potential loss of productivity". Quite so, but that's where it helps to listen to the users: you know when a failure is going to cost you a lot of time, and when to apply a preemptive patch or fix; and so do we, often enough that it is worth while to ask the user. I'm not saying this is a good idea campus-wide or enterprise-wide, but speaking as a faculty member in a CS department? Trust me, as Sledge Hammer said, I know what I'm doing.

  • 4. Respect the users' specifics. When I call Cox Communications to report a cable ISP outage, the first thing I am asked is how many computers I have on DHCP; when I call Dell to report a component failure in my desktop system, no questions about the system are asked until it is established whether I have the original factory-loaded OS. "I run my own NetBSD firewall with NAT" is immediately answered with, "well, don't do that". There was even a time (2000-2001, IIRC) when Cox would support Windows and MacOS, but not Linux - at least not officially. Once, I had a 56K modem fried by a surge. "It's 2000; I have replaced the original Win95 from December, 1997 with Windows 2000" was met with "we can give you a warranty replacement, but first you have to format your HD and reinstall Win95 to run our diagnostics." Every time I get a bluescreen or lock-up in Windows, or even an X-Windows hiccup in Linux, people tell me I have "too many windows open". Actually, they tell me I am using too many GDI resources in Windows, which may indeed be true (my typical WinXP session includes 6d4 Internet Explorer windows, a Mozilla Firefox session with 10-24 tabs, 2-20 Outlook Express windows, 6-16 Explorer windows, and sundry instances of Windows Media Player, Trillian, Nero, Azureus, Photo and Fax Viewer, Word, Acrobat, Penguinet, Task Manager, Notepad, WEKA, Neurosolutions, and BNJ). The thing is: we run what we run for a reason (generally for research and teaching, in my case). We need our specific combinations of applications, and while we are willing to simplify the configuration for diagnostic purposes, what we are running when something crashes is often typical of our usage patterns. My personal philosophy of computing is that if it doesn't work under normal everyday usage patterns for a particular user, it does not work. There is a reason Microsoft has a facility in Dallas where systems testers are paid to configure systems the way corporate clients have them set up, and attempt to reproduce reported enterprise-wide problems. Of course, every systems guru and his brother is reading this and thinking either "I'm glad I don't work for that branch of MS" or "MS pays a prettier penny than we get for that". True, but when it all comes down to it, the choice you offer a user when you ask him or her to uninstall or shut down an application (not just for testing but for good) is to accept decreased functionality either way: by removing existing programs and services or by giving up on the new one. Sometimes this is the only way, but oftentimes there is a workaround, which is what your typical user is looking for.

  • 5. It is not always fair to suppose that a competent user can see his or her way clear. A sysadmin will often look at a problem with the supposition that if his or her setup is the same as the user's, then the user has access to the same solutions. One thing to consider is that problems are cumulative, be they as mundane as disk fragmentation and bad clusters or as exotic as a warwalker or other cracker using packet-sniffed passwords to leach bandwidth and disk. The bottom line is that when something is broken on a system, the user's ability to perceive solutions is diminished. This problem can be purely psychological. For example, it took me months of paging through the Quarantine wizard in Symantec Antivirus (then Norton) before I realized I could go in and delete the infected and quarantined files. Seeing the wizard come up on many of my lab systems tells me that my students had some of the same habits or apathies. The problem can also stem from occurrence of two errors that overlap in time. They need not be simultaneous in onset: For example, I have had printing and Samba, printing and SSH, and IMAP and SMTP fail at two different times but only noticed at the same time, and thought in each case that it was one problem. To compound the confusion, I have also been locked out of multiple services for no apparent reason before, a problem that was sometimes diagnosed as a transient fault. What tools does a sysadmin have at his or her disposal to combat this problem? Sometimes he or she has access to a working system. Most often, though, he or she does not have access to the same fault. For example, I sometimes have nameserver issues with my ISP (Cox Communications) that Southwestern Bell DSL users will not have. An adminition I often give my student sysadmins is that "You have to try it as me." This doesn't always work, and it isn't always feasible, but often enough, the sysadmin's configuration files are just a tad bit cleaner and a quick su - reveals the problem.



As always, thanks for reading, and I hope this gives you a bit of food for thought. The opinions expressed above are solely my own and I take responsibility for them. Feel free to concur or disagree, but please do tell me why either way.

--
Banazir
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments