Log in

No account? Create an account

Previous Entry | Next Entry

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.


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.


  • 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.



( 2 comments — Leave a comment )
May. 2nd, 2005 05:26 am (UTC)
2. 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.)

I worked as one of those lab techs (it was conscripted service for my helpdesk job in college, we were required to put in a certain number of hours as a lab nanny). A majority of users didn't care despite my best efforts to teach them. I think your supposition that it's due to apathy on the tutors is misdirected, I think that what you are seeing is representative of a general trend in American culture.

I also think that the use of an FTP program is losing it's utility as a benchmark. FTP has specific functionality, and depending on the network setup at your particular university du jour it may never be necessary. However I would move that any cs graduation student that can't figure out how to work an ftp program even never having used one before needs to be removed from the program before. Learned functionality and conceptual understanding are not joined at the hip.

people are less and less interested in learning the technical skill of computing ... through experience and interaction, and more interested in acquiring technical certifications through passive learning

My current job is customer support as you know. We don't have stringent requirements on who we hire and we generally have a fairly good turnaround (intentionally due to the particulars of the company we generally like to rotate a class to internal projects every couple of months) so we interview lots of people on a fairly regular basis. I have interviewed a fairly large number of people who have certifications (everything from A+ to MCSE/CISCO certs) and I have not passed one of them. Not a single one of them is capable of a level 1 rep job at my company.

My mom's elementary school (or more particularely the one were she works as an administrative assistant) recently failed to renew the contract for their MCSE certified tech, because he spent three weeks trying unsuccessfully to resolve a problem with their printer (the problem when an outside tech was contacted turned out to be an empty ink cartridge). While this is an isolated incident it is in some ways representative of your average certified techs troubleshooting prowess. Frankly if you can't figure out whats wrong on your own the odds of you teaching an end user how to figure it out on their own is slim to none.

4. This is a symptom of how rapidly we teched up. There are to many people and to many configurations and to much of a derth of people who could actually support that kind of variety. Those people who are capable are generally to expensive to roll out a tech center with them (especially when 99.9% of your calls are of the luser variety, people who are capable of that variety tend to be driven batty by the endless repetition of the luser calls).

5. AMEN. Though there are two sides of this coin when it comes to competent users.

I can't tell you how many times level 1 reps advance an incident to me that has a simple and standard fix. The problem is the rep assumed the end user had tried it, and the compentent end user tends to overlook the obvious answers in favor of the more difficult ones. I would be a rich man if I had a dollar for every compentent end user that tried a variety of complicated fixes for what was actually a bad install and was easily fixed by simply removing and reinstalling the app.

The other side of that coin is what is wrapped up into a point you made initially. Just because a user is compentent does not mean they have had the time to reach a level if high compentency with each particular application or system they use.
May. 2nd, 2005 10:06 pm (UTC)
> you get CS graduate students who arrive on campus never having used FTP. > (You think I'm kidding? I wish I were.)

Ok. You have a point there. But you also gotta remember that there's so many other tools to learn. It would be easier if it we just had to learn a few unix commands. We'd all be experts in it. But now we've to learn perl, php, jsp. Use tools like ant, junit etc., etc.,

Info overload man. I think you can be forgiven if you haven't used WinSCP, or putty before.
( 2 comments — Leave a comment )

Latest Month

December 2008

KSU Genetic and Evolutionary Computation (GEC) Lab



Science, Technology, Engineering, Math (STEM) Communities

Fresh Pages


Page Summary

Powered by LiveJournal.com
Designed by Naoto Kishi