System Administrator Ramblings
As I’ve developed/administered/used more and more web apps, one come deficit has become more and more annoying: Most web apps do not have an easy way to undo changes.
This has many ramifications, but I think the most damaging is that it forces most administrators to set user permissions on the basis of the minimum permission model. While this model is great if you don’t trust any of your users, most of us in the server administration field don’t have to be quite so paranoid. Instead, we are forced to use the model because users can not be trusted to read documentation or even to thing in a rational manner, and thus will end up doing something stupid (like deleting most/all of your data). If actions of this nature were easy to audit and reverse, I would not have to give a thought to idiot-proofing the system — I could instead concentrate on merely constructing a permission structure that protected my employer’s IP.
The main obstacle to such systems (storage) does not in fact still exist, especially with the advent of services like S3, where the cost of the storage could be pennies. If you are squeamish about such a new-fangled thing, try NearlyFreeSpeach.net — they only charge you for the disk space you use, and they are extremely reasonable (and you can run MySQL on their servers)
The only webapp that I routinely use that has this property is MediaWiki, the software behind Wikipedia, et al. MediaWiki is an administrator’s dream — put it behind http auth that everyone at your company knows. You can even make everyone an administrator — all admin actions can be reversed using an extremely well thought out and simple interface. It really makes me wish that Atlassian, the current source of my frustration, would add this capability to their projects, but it won’t happen since the entire architecture was apparently designed by an architecture astronaut (plus, they used Java as an implementation language).
Basically, my entire frustration comes down to my belief that I, as a systems administrator, should strive to provide service to my clients, not throttle it. In other words, when designing any system, I start by assuming that my users never take actions with malice — instead they just don’t read the docs and have never really formed an adequate mental model of how such systems actually work.
Furthermore, if you are a system admin, you probably have had the experince where you’ve set up an awesomely secure system for performing some task (say bugtracking), and the users seem to be happy (as happy as users ever are). However one day, a user comes timidly into your office and asks you to fix a problem they are having. It probably seems like an odd problem to have, but you sit down and hammer at it anyway. Several hours later, it dawns on you — the users have rebelled! Somehow, they’ve managed to take your system and turn it into an unmaintainable, insecure, inefficient mess that still is somehow more useful to them then your system. You can train them in how the system should work all you want, but it avails you not at all (users are probably the most stubborn creatures on this planet). Finally, you decide to wash your hands of the whole system and give up trying to make their lives better.
As a case study of sorts, take the UO’s Banner system. Banner is a system for managing institutions of higher education. It is written in Oracle Forms, and it runs on an Oracle database. The user interface is a weird melange of a Java applet and a Java application that requires a special program (Oracle JInitiator) to be installed on every client machine. This system is awesome from a management point of view — you can see at a glance (given the proper permissions) how the university is running at the moment. Students can register/drop/manipulate their classes for the term without the intervention of a human. All is good. But, take a closer look — I guarantee that the vast majority of departments have what they call a ‘shadow system’ that they use. Basically, the system provides them with an interface for doing something (accounting is a popular choice) in the way that is easiest for them. The software then translates this information into the bizarre formats that Banner requires and uses and uploads it. Never mind that the registrar has prohibited departments from using such systems to manage graduate student registration — I know of at least two departments that still use one due to the sheer annoyance factor associated with doing work in Banner (I even wrote a large part of one of those systems).
The problems with the Banner system pretty much boil down to the fact that Banner is treated by central IT as a way of coercing ‘correct’ behavior out of departments rather than as a way of increasing productivity of the departmental staff.
This probably runs against everything you were ever taught as a system admin, but just try it — it turns out to actually be less work in the long run, and as a bonus, your users will start actually liking you, since they no longer feel that they are fighting against a computer to do their job, but are instead being helped by one.
