|
|
|
|
|
by EdwardCoffin
688 days ago
|
|
This passage particularly struck me: He noticed when a technician on a call began by examining copies that had been thrown in the trash and deduced from them that the problem with the machine was different from what the customer had reported. “The trashcan is a filter between good copies and bad,” one technician explained “Just go to the trashcan to find the bad copies and then… interpret what connects them all.” On a related note, I'd like to highly recommend Lucy Suchman's work, mentioned in this article as Plans and Situated Actions: The Problem of Human-Machine Communication, but the updated version now called Human-Machine Reconfigurations: Plans and Situated Actions. The new version has several extra chapters and some other revisions. I've read it several times, and had my mind blown each time. |
|
One of the first things I ask someone now is to give me their test prints for the last few changes they've made and what they changed, if they remember. Nine times out of ten, just looking at other factors, I've been able to pinpoint what's wrong.
Interestingly, this has also led me to a few "is it turned on" questions, the first of which is "when is the last time you tightened all the bolts that should be tight and loosened the bolts that should be loose?" The simple act of making sure tight things are square and tight has resolved many an unrelated problem because it makes you check so many different parts of the machine.
This also correlates with one of the takeaways from the old Computerworld column called Shark Tank. The most common aspect of the solution was to simply go and observe the failure, because so often it was an unaccounted for externality -- such as a cleaning crew unplugging something at 2AM when a system would "mysteriously" go down.