Just after I posted “Erratic cellular settings” I thought about cars and problem solving.
Long ago I learned a little story about car problems that may have been older than me.
A car dealer gave his wife a new car. She was delighted with it, but she complained that it ran erratically. A mechanic checked it out and could find nothing wrong. She brought it in again with the same result. Finally, the head mechanic went out with her.
She started the car, pulled out the choke, and hung her purse from the choke.
Sometimes, you have to just be there to solve a user’s problem. I found this out when a user couldn’t access a document because his computer terms didn’t the same meanings as others did. I had to go to his house to understand the problem. I found out the cause of an error in my own software when I saw a user print a document on his on printer. I had assumed a negative number for a printer line would not get printed. It worked fine on my Apple printer, but it didn’t work on his third party printer.
The problem with computers is that the designers expect their users to be expert car mechanics, masters of intricate analysis of problems. But all the average user wants to do is touch a few buttons or type a few words to get his or her work done. If their cars sputters when it should purr, they take it to a mechanic who often can diagnose the problem within an hour. But if their devices sputter when they should purr, they are expected to put in hours trying to get enough information to get somebody to finally make a correction to the software (or tell them not to hang their purses on the menu bar).
My plaint about all this complexity is whatever happened to the “Computer for the Rest of Us” (The 1984 Apple Macintosh)?
Showing posts with label solutions. Show all posts
Showing posts with label solutions. Show all posts
Monday, January 11, 2016
Wednesday, April 09, 2014
Making systems work: The psychology of business systems
This is the title of a book by William C. Ramsgard, Wiley, 1977-09-29 and the quotes that follow are from various scraps of paper that have been gathering dust on my desk.
“The successful information system provides all the related and general xpj requirements for operating personnel, based on normal organizational activity. New information requirements are always modifications to the existing information system and are fulfilled by a minimum caretaker staff without disruption to existing informational and organizational structure or substantial additional resource allocations.”
From a note in ABC Stenoscript and http://books.google.com/books/about/Making_systems_work.html?id=RkBZAAAAMAAJ
From another note on this book
“Peasecod’s Parameter
When the time recorded in the maintenance log approaches the original systems development time, the existing system is dying and the systems cycle should be repeated for a complete new development of the system.”
From another note in ABC Stenoscript
“Systems should be built not to solve problems but to provide opportunity.”
“The successful information system provides all the related and general xpj requirements for operating personnel, based on normal organizational activity. New information requirements are always modifications to the existing information system and are fulfilled by a minimum caretaker staff without disruption to existing informational and organizational structure or substantial additional resource allocations.”
From a note in ABC Stenoscript and http://books.google.com/books/about/Making_systems_work.html?id=RkBZAAAAMAAJ
From another note on this book
“Peasecod’s Parameter
When the time recorded in the maintenance log approaches the original systems development time, the existing system is dying and the systems cycle should be repeated for a complete new development of the system.”
From another note in ABC Stenoscript
“Systems should be built not to solve problems but to provide opportunity.”
Wednesday, March 12, 2014
Malaysia Airlines and problem solving
It is very hard to imagine the anguish of the relatives of those on the missing Malaysia Airlines flight, but we should give some slack to those involved in trying to determine what happened to the flight.
I’ve been involved in several computer situations in which crucial information was not available at the outset. It was only when the right question was asked or the right information was volunteered did a solution become apparent. All of these situations were much simpler than the tasks facing the Malaysian and other investigators.
My first memorable lacking-information problem was in Sweden. One customer’s mainframe kept crashing. We looked at memory dumps, we asked questions, we had meetings, nothing became obvious. It was only when I had a copy of a program that often seemed to be present when the computer crashed that I was able to take some more deductive steps. The customer had not upgraded their software from a version that had a memory violation. That program crashed at other sites with the same software. Thus, the memory protection of the crashing computer was faulty. The technicians fixed the memory protection problem, the subject program crashed, and the customer upgraded the software.
My latest memorable lacking-information problem was in Duluth last fall. The keyboard on my MacBook Pro locked up. None of the proposed solutions in the user community seemed to last for long. I took my computer to the Geek Squad. They kept it for a few days and found nothing wrong. I brought it home and the keyboard locked up again. After a bit of head scratching, I realized that the tech shut down all my applications before testing it. Then I figured out that MicroSoft’s Outlook was the problem. I reorganized Outlook’s database and the problem went away.
I hope those investigating the Malaysian Airlines crash find that crucial missing clue soon, but the ocean in that area is bigger than one laptop or one 1970s mainframe.
I’ve been involved in several computer situations in which crucial information was not available at the outset. It was only when the right question was asked or the right information was volunteered did a solution become apparent. All of these situations were much simpler than the tasks facing the Malaysian and other investigators.
My first memorable lacking-information problem was in Sweden. One customer’s mainframe kept crashing. We looked at memory dumps, we asked questions, we had meetings, nothing became obvious. It was only when I had a copy of a program that often seemed to be present when the computer crashed that I was able to take some more deductive steps. The customer had not upgraded their software from a version that had a memory violation. That program crashed at other sites with the same software. Thus, the memory protection of the crashing computer was faulty. The technicians fixed the memory protection problem, the subject program crashed, and the customer upgraded the software.
My latest memorable lacking-information problem was in Duluth last fall. The keyboard on my MacBook Pro locked up. None of the proposed solutions in the user community seemed to last for long. I took my computer to the Geek Squad. They kept it for a few days and found nothing wrong. I brought it home and the keyboard locked up again. After a bit of head scratching, I realized that the tech shut down all my applications before testing it. Then I figured out that MicroSoft’s Outlook was the problem. I reorganized Outlook’s database and the problem went away.
I hope those investigating the Malaysian Airlines crash find that crucial missing clue soon, but the ocean in that area is bigger than one laptop or one 1970s mainframe.
Subscribe to:
Posts (Atom)