The MS easy rider crashes again

The stories of users migrating from Microsoft Windows to a Free Software
alternative (or attempting to do so) have usually had one large sticking point: The
alternatives are much harder to learn than Microsoft Windows. Conventional 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. I beg to differ.My own tale began during my last job, where I worked 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 NT4 and Exchange. All the
training and staff computers ran Windows 98, and we used 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 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 only use Microsoft product. 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 a hassle, and it
would have required some rudimentary training with the staff to make sure
someone could maintain the Web server.

Also, the Windows NT server kept having odd problems.
Remember, the management wasn’t willing to train anyone to maintain it;
instead they sent down a technician once in a while to poke around at it. So we were
left with an unstable server, and quite often, unhappy customers not being able
to do their courses. 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.

Regardless of the obstacles, I implemented a Linux system while I was with the company,
and it helped us keep track of all our clients and their progress. The staff
loved it — it saved us time, allowed us to give higher quality service, and it was easy to use. No annoying features we didn’t want; it was
customised to our exact needs. Yet, 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.

There is a direct parallel between my experiences in an office that didn’t want to spend money on expertise, 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 answer 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 Microsoft’s reputation than high-profile benchmarks can ever undo. They have also helped to
propagate endless viruses, facilitate many a major 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 United States (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.
While 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 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 learned x, y 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.