The Easy Rider Crashes Again
The story of users migrating from Microsoft Windows to a Free Software alternative (or attempting to do so) has had one large sticking point: the alternatives are much harder to learn than Microsoft Windows. Recieved wisdom says that when GNU/Linux, FreeBSD and others become as easy to use as Microsoft Windows (or when Microsoft's EULAs become too unreasonable), the migration will be inevitable, and it will be a good thing for all. If we can make that bridge to allow those migrating to cross it, all will be well. I beg to differ.My own tale begins in my last job, working as an IT trainer in a small firm whose name I shan't mention. My duties included teaching clients (one-to-one), maintaining the training computers, and occasionally making sure the server was still running OK. The whole office ran on Microsoft's software; the server ran on Windows NT4, and had Microsoft Exchange as the e-mail server. All the training and staff computers ran Windows 98, and we all used Microsoft Office and Outlook for most of our work.
It seemed like a happy solution on the surface, because everything was integrated and worked. But there were cracks in that picture, due, I believe, to the philosophy that has consumed the IT industry ever since the a marketing department managed to put the words "easy" and "computing" in the same sentence.
To begin with, we didn't really just use Microsoft's software. We had a package called Janna to manage our contact database, and then had a horrible time switching between Janna, Outlook, Word, Excel and a filing cabinet to keep track of things.
We could have set-up a really well thought out system using customised groupware, such as a solution using a web server and a modified version of a Free PHP groupware suite. But that would have been more hassle to set-up, and it would have required some rudimentary training with the staff to make sure someone could maintain the web server.
I actually implemented a system using a web server while I was with the company, which helped us keep track of all our clients, and their progress. All the staff loved it... it saved us time, allowed us to give a far higher quality of service, and it was easy to use. No annoying features we didn't want; it was customised to our exact needs. When I left the company, they scrapped it, because the management didn't want to train another employee to learn how to reboot GNU/Linux (I even offered to train them). So they went back to a mis-mash of applications and paperwork.
The next problem was that the Windows NT server kept having odd problems. Management weren't willing to train anyone in our centre in maintaining it; instead they sent down a technician once in a while to poke at it. So we were left with an unstable server, and quite often, unhappy customers not being able to do their course. The problem was that it was just too easy to tell us which buttons to click on to do normal tasks, and then leave us to it.
Management wanted a solution whereby we were shown what to do, without knowing why, because it was quick and easy.
There is a direct parallel between my experiences in an office, and the wise words of Larry Wall, the creator of the Perl programming language. In a recent Slashdot interview, he was asked for his opinion on Perl, and the difficulties in getting several people to work with the same code. His asnwer was simple:
"you wouldn't expect to hire random people off the street to come in and collaborate on writing a novel. You can do it by hiring a few good novelists who already know how to figure out how to work together, or at least how to fight with each other productively".
Programming is not meant to be easy. What Larry was saying is that if you make it too easy for programmers, then poor programmers will be able to do things best left to good programmers, and will inevitably do them poorly. Everyone will suffer in the long-term as a result.
I am of the opinion that the same applies to computing and server administration: if you make it too easy for people to administrate systems, then poor administrators will do the job, and do it poorly. Better to keep it (relatively) difficult, and keep the administrators of a high quality. That way you may have to spend a little more training and retaining the staff, but you will benefit in the long run.
Untrained administrators, with a poor understanding of their server, from the service acronyms to the administrative GUIs, cause more harm than good. Wide-open servers have done more damage to the reputation of Microsoft's software than high-profile benchmarks can ever undo. They have also helped to propogate endless viruses, facilitate many a majoy cracking scandal, cause endless crashes in offices small and large, and bring about all kinds of other problems to people working with them.
This attitude of cheap and dirty vs expensive quality is something that applies to the very philosophy of management, and especially IT management, in the U.S.A (and increasingly in the rest of the world). The philosophy of Microsoft and others is only accelerating this, promoting the idea that it is a good idea to get unskilled people to maintain "easy" systems that are, in reality, very complex.
It is a similar, but not identical story with desktop users. When teaching people to use Windows or Office or Photoshop, the most frequent problems people had were due to them not understanding the computer they were using. I, and other trainers, frequently had to sit people down and explain what was going on. Whilst Windows was quite happy letting people think in terms of moving "files" between "c" and "a", we found that talking with students and explaining what files are, and what "a" and "c" meant, helped them immeasurably. Many people would claim that you shouldn't need to understand about hard drives and file systems to use a computer, but these students, even 80 year olds, benefitted from knowing it.
I am of course not saying that you should teach every desktop user about mounting devices and memory management, but a deeper understanding of the computer can make day-to-day use far easier and much more rewarding. Though at first people would insist that "they don't want to know x, they just want to know how to do y", once they learnt y, x became obvious.
By analogy again, when you take driving lessons you learn a little about your car, its engine, chassis, steering, how they react in different weather conditions and, to some extent, why, even though you just want to learn how to get the car from a to b. We couldn't dream of letting motorists onto the road only knowing that "this pedal makes you go, this one stops you. This turns you left and right". Similarly you wouldn't let an unqualified person drive a large freight truck just because the controls had been made easier to understand. So why do we persist in trying to do the same in computing? Rather than making the bridge for people, it is time we just made sure they learn how to make it themselves.
This article is copyrighted by Tom Chance, 2002, under the GNU Free Documentation License. As such, the article may be reproduced free of charge so long as this notice is preserved and the author, Tom Chance, is notified.
It was published by Newsforge and Tinyminds.org, and in the September 2002 edition of the La Crosse PC Users Group newsletter (download the PDF here).
