auto repair
I have a theory about auto repair. Up until now, I pretty much bought in to the idea that cars (engines, mostly) have gotten so complex and so computerized that there isn’t much a mechanic can do, other than rely on the computer diagnostic codes and replace expensive modules.

I have my car in the shop right now because I had an episode a few days ago where the engine slipped into a lurching idle and then was weak and lumpy at speed (like one cylinder wasn’t up to snuff). After talking to one of the guys at the shop (I don’t even know what he does, I think he is probably more a salesperson than a mechanic) about what they are going to do to it, I had an epiphany.

I don’t really buy their rationale about what they have to replace. It boils down to “thats what the computer says is wrong ( a faulty idle speed motor ), and besides your explanation of the symptoms reinforces that, even though I didn’t understand all the symptoms before reaching this conclusion. But, if that doesn’t do it, I am sure this other part will complete the repair (a neutral safety switch, which sounds totally unrelated ).”

Unfortunately, the problem has proven to be intermittant, so I’m not sure what options I have.

But, here is my epiphany:

The real “problem” with auto repair today is the result of a gradual cycle of evolution dominated by two interrelated factors.

1. Computer Diagnostics have made some diagnoses easier to make.
2. The diagnostic skill of mechanics has dropped.

It doesn’t hurt that both the auto industry and the auto repair industry have a vested interest in this state of affairs since it:

1. Decreaces labor costs by reducing the skill level required of mechanics.
2. Increaces the average cost of repairs, thereby increacing revenue.

Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they’re dedicated designers and don’t have patches to implement their suggestions.
from Why Free Software usability tends to suck

This is an excellent point!

I am less enthusiastic about one of his later points:

Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternative.

I think it is more often the case that many hackers miss the nuances in what Apple or Microsoft does and so end up with a UI that superficially resembles that of a similar Apple or Microsoft product, but doesn’t work nearly as well.

I suppose this is another danger of imitation, that you don’t understand the reasoning behind the component you are copying and so might miss important subtleties.

But then there is this:

many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface

Fifteen Pixels of Fame!!! I love it!

Reading other people’s source code can be really handy.