Perhaps, but the engineering of physical goods is a poor analogy to software, considering the relative ease of changing things in software if you decide they aren't working.
(Also to bdhess) just a note that I'm not trying to say the right thing for a car is also the right thing for software, just that the contrast between the design philosophies is funny (haha and/or peculiar).
To be fair, you did argue that it would be nice if software engineers showed "craft," which suggests that you think the way software is done is the wrong way.
I don't think there actually is a contrast in philosophies. The philosophies are the same for each: do a cost/benefit analysis, and then go with whatever makes the most money.
It just happens that the cost of fixing an automotive defect (i.e., with a recall) is generally way higher than the cost of fixing a software defect (i.e., by shipping an update). So the automotive industry invests more heavily in eliminating defects.
Certainly the philosophy when you're developing software for medical devices or rockets is more rigorous and careful, but the speed would be pretty much unacceptable for, say, Facebook.
Yes. And there's the inherent problem in arguing with analogies.
Here's another analogy:
"This car seats twice as many people, and accelerates twice as fast, but sadly will require twice as much motor oil when it's time for an oil change. We could have optimized and improved the car's design, but you would have had to wait two more months and it would've added $10,000 to the unit cost. It would've been madness to do."
We could sit here all day arguing about which analogy captures the actual situation correctly, or we could just talk about the actual situation.
