Web-Site Foolishness Since 1992
Rick’s Pages

 

 

 

 

m3

 

 

A Rant – Boot Your Computer!

 

 

As a career software professional, I feel I have the right to compose this rant. It was probably written during one of the many times the job drove me crazy. The hard-copy I transcribed here wasn't dated; from the content, I estimate it was written in the early 90s.

The original outline has been simplified for presentation here, and I've updated the text a little. You may find this rant a bit heavy-handed, but I did warn you it was a rant.

1. Clothes Don't Make The Man. Just because you have a computer doesn't mean you know how to program or use it.

  • Amateur Programmers. All that we have learned over the years with regard to computer programming is being ignored. No longer do we have experts handle the complexities of programming; we let the users try. What do we end up with?
    • Lack of System Analysis. What problem is being solved? Is it well understood? Does it require a computer at all? Of course, the BASIC programming language had already promoted "user" programming decades ago.
    • User Interfaces are often not planned. What seems logical to the developer is not necessarily logical for the average user.
    • Reliability. Programs are often not tested for user errors. Usually no thought has been given to failure modes and recovery.
  • Amateur Artists. Having a drawing program doesn't make one an artist. Also, you can waste tremendous amounts of time drawing complex graphics when simpler sketches would do.
  • Desktop Publishing. Sure, it's sold lots of laser printers, large monitors and more powerful computers, but nobody's taught people the right things to do.
    • Spelling and grammar. People write their own documents and memos and many can't spell. Without assistants and secretaries, many managers turn out writing that would embarrass high-school students.
    • Lack of esthetic quality. There is such a thing as proper use of fonts, emphasis, and writing style. Sadly, this type of stuff is now showing up in written publications. The lack of the comma-shaped quotation marks, the use of ALL CAPS for emphasis, things like that.

2. Electronic Mail. While e-mail is generally useful, especially over long distances, the proliferation of incompatible mail systems continues. Everyone has different needs, and, therefore, different systems are developed.

At the time, we had QuickMail (for Macs on a company network), AppleLink (Apple's own worldwide email system), Internet email, and a few folks even used AOL. What a mess. [Today, everyone uses Internet email, so this doesn't seem to be as big a problem as it was back then.]

What about the excuse factor for e-mail? There are a dozen excuses you can give for failing to act on someone's email. As a result, email should not be considered a fully reliable communication system.

When will it arrive? People don't understand that an email can be delivered in five seconds or five days. You have no control over the intermediate hops it takes. If it's a timely message, use the phone.

3. Some Absurd Uses Of Computers. It always amazes me that people persist in using computers to "solve" problems, whether the problem requires a computer or not.

Multiple-User Access. Consider the case of more than one person updating or maintaining some database (e.g. a calendar).

  • A computer-based appointment calendar. Typically, a manager and his secretary can both update the calender, but neither would really know what's going on: either person can change the calendar, and they don't have to personally communicate the changes any more. Even if both parties are careful to always check for the latest calendar data, what happens if there's some delay in the update process? What if the phone rings and someone forgets to finish entering the data? The result is confusion.
  • Laptop Computers and PDAs. How can someone else, especially someone not computer-literate, check your calendar when it's inside a complicated little computer? Everyone can read a paper appointment book.

Balancing Your Checkbook. While it is sometimes useful to have a computer analyze expenditures at tax time, using the computer to perform routine calculations is ridiculous. Carry a five-dollar calculator along with your checkbook and use it.

Check-in/Check-out Systems. Amateur-developed check-in systems don't work.

Employee Check-In. An experimental employee check-in system at my office was removed shortly after installation. Its developers found that the system failed to meet the needs of its users and the company's security personnel. (One wonders whether the developers even asked, or whether they simply presented their creation to the world.)

As users of the system, my colleagues and I often found shortcomings in the system. Although its barcode reader handled employee badges fairly quickly, there were some situations that required considerable typing. "Unauthorized Personnel," like visitors and non-department employees, often caused processing delays while we tried to figure out how to get the system to accept them.

To "authorize" someone, you had to enter things like badge number, visitor information, and other data. (Of course, there was no oversight as to who you authorized, nor did we know whether the new data would be stored for future use.)

If a visitor tried to fill in the information, it could take several minutes. During this time, the system was unable to do any other processing; in these cases, we often just waved at the guard on our way in or out of the building. When employees from other departments attempted to scan their badges into the system, it reported that they were unauthorized. Our department, of course, had no direct control of the authorization database being used by the system.

I think the last straw was when one of my colleagues found that he could scan grocery barcodes into the system and authorize them. I considered carying a can of sliced peaches in lieu of my employee badge...

Here again is a failure of a system because needs were not analyzed before beginning implementation. We went back to using a simple sign-in book at the guard station. The guard, who could never really see the computer screen, could now verify that you actually signed in!

 

The Apple Child Care Center, at the Apple Cupertino campus in the late 1980s thru early 90s, replaced a manual child check-in system with a computerized one. The manual system consisted of a simple, reliable set of ring binders and sign-in sheets. Each of the three child classes had a separate binder; there was one sheet per child: an entire month's sign-in and -out information fit neatly on one page. Notes to parents were easily handled by sticky notes attached to the page.

Everyone understood the manual system, since all it required was the ability to read and to sign your name. Proper identification could be verified manually by the lobby receptionist, and everything worked smoothly. The binders were replaced by the more expensive computer system, but the receptionist still had to verify the identity of the person arriving.

In all fairness to the Child Care Center folks, maybe it was the same folks who created the employee-checking system who suggested they use this new system. The two systems weren't the same, which may be even worse: perhaps it was another well-meaning group of programmers who built this!

So what's wrong with this picture?

  • No power-fail or disaster protection. In the event of a power failure, the paper system worked flawlessly. The computer, on the other hand, would be unavailable and therefore wouldn't serve its necessary purpose — that of tracking attendance. In an attempt to rectify this, they began printing hourly attendance reports. Those reports were lengthy, used far more paper than the manual system, and tied up the system for several minutes during printing. During a natural disaster such as an earthquake, accounting for all children is perhaps the most important task of the facility. Having all the attendance records locked in an inoperative computer system is, in itself, a disaster.
  • Delays during check-in. Because a single system replaced three sign-in books, occasional delays occured because all parents used the same system, regardless of the child's class assignment. This delay once caused me to walk in with my children, drop them in their classroom, and leave without remembering to sign in. The cause of this inexcusable error was the computer. As far as the attendance system knew, I never left my kids there that day.
  • Another time, the computer was busy printing reports. Because it would be unavailable for several minutes, I did exactly the same thing. The irony here is that the reports caused both situations; these were the same reports that were to be a stopgap to cover for the shortcomings of the system!
  • Management analysis of data? Data collected by the system could be analyzed in some back office, but in this case the data seemed rather useless. They could get daily attendance figures more easily by a simple head count. In many cases the ability to analyze data is an excuse rather than a need. After all, if it's being collected, someone should look at it, right? Maybe we need some more 3-D bar charts.
  • Equipment cost. The system required a fast, expensive computer (for its time) because the software ran too slowly on a lower-cost model. The printer was deemed necessary, as mentioned above. The capital-equipment cost eclipses the few dollars' worth of paper and binders that were used in the manual system, and it didn't eliminate any labor.
  • Not friendly to novices. While my mother was authorized to pick up my children from the Center, she most certainly couldn't use the system without help. One of the staff had to drop everything and help. With the manual system, she never had any problem signing her name. Still doesn't.
  • Are backups maintained? What if the system hardware fails? Is there an alternative method of solving the problem? Will data be restored promptly and properly, or will we simply suspend normal procedures while the computer is being fixed? "Don't bother, just take your kids home. We'll figure things out eventually." My suggestion: Fall back to the binders. In fact, use them all the time. Sheesh.

 

A product to replace the in/out status board. A software product came out to replace the familiar "In/Out" board with a computer program. Office workers would simply check in and out with the program, rather than using a manual status board. Status can be checked (and changed?) over the network from any computer.

  • Is it convenient to use? If we all remembered to check in and out from our computers (or at the front door), the system could work. But, being human, we often forget. An in/out status system, whether manual or computerized, is only as good as the people who (remember to) use it.
  • Remote access. What if I call in and say I'll be somewhere else after leaving for lunch? Who updates my data? This situation encourages the removal of all security, so that anyone in the office can make changes. After all, leaving a phone message for a secretary doesn't help with timely updates.
  • This, however, brings up the security problem. What prevents a disgruntled co-worker (or a prankster) from telling the system I've gone to the beach for the day?
  • Manual reversion during disasters. I covered this above.

4. People Are Enslaved By Their Computers. Tremendous time and effort are expended programming computers and trying to use them to do unnecessary things. The answer is to analyze the problem and decide whether the computer really can help. Just having a tool isn't the whole answer.

5. More Software For Software's Sake. This one's pretty farfetched, I'll admit. I've spent 20 30+ years working on and with Unix operating systems. People claim Unix isn't user-friendly, but they don't realize that Unix was written for programmers to use, not average users. Anyway, one of the best uses for Unix is as a platform upon which to develop software. It's got all the tools a programmer needs; in fact, there was once a software package called The Programmer's Workbench back in the 70s; it's long since been included into all Unix systems.

So what do you get if you're writing more "stuff" to make Unix better? You get a system that allows other programmers to write more software. This is sort of like becoming a philosoper: the best gig you can get is a job teaching more philosophers!

Copyright © 1995-2016 - Rick Auricchio