Quantifying Trade-offs in Engineering Decisions: A Utilitarian Approach

1. Starting with a Thought Experiment

Someone once posed an absurd question: How many chickens is a human life worth? While often dismissed as a philosophical anecdote, it touches upon a genuine engineering dilemma. When two values cannot be directly compared, decision-makers still have to make a choice. Deciding whether to invest in fixing a security vulnerability or setting stricter alert thresholds for a service requires comparing different outcomes with incomplete information.

The value of such thought experiments lies in bringing hidden assumptions to the surface. Once we clearly define what is being compared, the units of measurement, and how pain or loss is quantified, discussions can shift from emotional reactions to logical reasoning. Different ethical frameworks have vastly different judgments regarding animal sentience and suffering, meaning the same set of numbers can yield completely opposite conclusions depending on the stance taken.

2. The Quantitative Logic of Utilitarianism

The fundamental premise of utilitarianism is that among available options, one should choose the one that maximizes overall gain and minimizes overall loss. At the computational level, the commonly used tool is expected value. For each option, you estimate the possible outcomes and then calculate a probability-weighted sum.

The formula for expected loss is: Expected Loss = Incident Probability × Loss per Incident. If the total cost of an option equals its implementation cost plus its expected loss, comparing two options simply requires comparing their total costs.

This method relies on three premises. First, probability estimates must come from historical data or testable models, not subjective guesses. Second, losses must be measurable in the same unit, such as money, downtime duration, or the number of affected users. Third, decision-makers must accept expected value as a valid basis for judgment. If any of these premises do not hold, the model’s output should only be treated as a reference.

3. Practical Applications in Engineering

In the engineering domain, the expected loss model is frequently used for risk prioritization. Security teams use risk matrices, where the x-axis represents occurrence probability and the y-axis represents impact severity, prioritizing risks with high probability and high impact. In capacity planning, teams multiply the probability of service downtime by the revenue lost per hour to determine if investing in redundant resources is justified.

In policy analysis, there is the concept of the Value of a Statistical Life (VSL), used to evaluate the benefits of public safety investments. It describes the cost one is willing to pay to reduce the probability of death by a certain margin, primarily serving resource allocation. The values adopted vary significantly across different countries, so sources, years, and applicable scopes must be clearly stated when used.

This distinction is crucial. Statistical-level calculations are used to determine where resources should flow, such as deciding which bridge to reinforce first. They cannot be used to judge whether a specific individual’s life is worth protecting.

4. Example: Comparing Two Solutions Using Expected Loss

The following code compares two operational solutions. Option A has a lower cost but a higher incident probability; Option B requires more investment but has a lower incident probability.

from dataclasses import dataclass
@dataclass
class Option:
    name: str
    cost: float           # Implementation cost (in 10,000 units)
    incident_prob: float  # Annual incident probability
    impact: float         # Loss per incident (in 10,000 units)
def expected_loss(opt: Option) -> float:
    return opt.incident_prob * opt.impact
def total_cost(opt: Option) -> float:
    return opt.cost + expected_loss(opt)
options = [
    Option("Option A: Enhanced Monitoring & Alerts", cost=20, incident_prob=0.30, impact=200),
    Option("Option B: Redundancy & Auto-failover", cost=60, incident_prob=0.05, impact=200),
]
for opt in sorted(options, key=total_cost):
    print(f"{opt.name}: Total Cost {total_cost(opt):.1f}")

In the output, the total cost of Option B is 70.0, while Option A is 80.0. Based on these parameters, Option B is the better choice.

However, the conclusion is highly sensitive to input parameters. If the incident probability of Option B rises to 0.15, its expected loss becomes 30, bringing its total cost to 90.0, which immediately reverses the ranking. Therefore, when using the model, you should conduct a sensitivity analysis on probabilities and losses to observe whether the conclusion remains stable within a reasonable range. If the conclusion only holds within a narrow margin, you should gather more data before making a judgment.

5. Boundaries of Model Applicability

Quantitative models excel at comparing resource investments against risk-benefit returns, but they cannot replace accountability. The following points require attention:

• For risks involving human safety, an unacceptable red line must be established first. Only options below this red line enter cost comparisons; trading higher human safety risks for lower costs is never permitted.
• Model inputs need to record their sources and assumptions for post-hoc auditing.
• Losses often include hard-to-quantify elements, such as user trust and reputational impact. These should be explained separately in reports and never ignored simply because they cannot be calculated.
• High-impact decisions should be jointly reviewed by multiple parties, including technical, legal, product, and frontline operations personnel.

6. Implementation Guidelines

When applying the expected loss model to actual decision-making, you can follow these steps:

1. Standardize loss units, prioritizing monetary values or directly convertible metrics.
2. Cite the sources of probabilities, prioritizing historical data over experiential judgment.
3. Conduct sensitivity analysis on key parameters and record the range in which the conclusion holds.
4. Set red lines for risks related to human safety and exclude them from cost trade-offs.
5. Save the inputs, outputs, and responsible persons for each decision to create a reviewable record.