Hard cases make bad philosophy

Crooked Timber is going through one of its periodic spats about philosophy and especially about the use of socalled trolley problems to tease out universal principles of morality. A trolley problem is a classic philosophical thought experiment which goes something like this: “A trolley is running out of control down a track. In its path are 5 people who have been tied to the track by the mad philosopher. Fortunately, you can flip a switch, which will lead the trolley down a different track to safety. Unfortunately, there is a single person tied to that track. Should you flip the switch?” Over time these sorts of experiments have gotten more complicated and less real, which is why every so often there will be yet another 100+ comment thread on Crooked Timber on them. Now this isn’t something I’d normally would pay much attention to, but Christ Bertram’s comment as to why these examples have to be extreme struck me:

There’s a perfectly good reason why the examples we use are “far fetched”, “ludicrous” etc. It is because we are often trying to test our commitment to some principle or other which is alleged to hold universally. A principle wouldn’t even be a prima facie candidate for such universal status if it failed to deliver the right answer in the central cases, so we are bound to seek out more exotic examples – it is the way of the dialectic.

The problem with that approach is that you end up spending a lot of time and effort into constructing an extreme enough edge case to satisfy the need for universality and yet more time and effort into defending your construct against critics pointing out its flaws, leaving the consideration of the principle in question as at best a secondary activity [1]. What’s more, by forcing yourself into creating such an extreme case there’s always the danger that you’re building it towards a preferred outcome—either to prove or disprove universality.

It’s like software testing. For any moderately complex piece of software it’s easy to spent a lot of time and money creating test cases that try the limits of the system, but which are rarely or never encountered “in the wild” and which say little about the more mainstream circumstances with which the software needs to work. [2]

[1] Classic science fiction example: The Cold Equations
[2] Like the financial/payment system at a Big Government Facility I know that has provisions for combinations of benefit payouts and such that are throroughly tested with each new release but have never been used in production…