The Problem with "Quality of Life" as a Metric

We keep using this term like it means something, but let's define what we actually mean when we say someone has a better quality of life. Is it subjective well-being? That can't be right because two people experiencing identical objective conditions would report different subjective states. Is it health outcomes? Too narrow. Is it economic security? Also too narrow. The honest answer is that "quality of life" doesn't exist as a unified metric, so using it to make any kind of comparison between societies or individuals is fundamentally meaningless.

The premise assumes there's a shared definition of quality, which is itself the problem. If you measure QoL by subjective self-reporting, your metric inherits the biases of whoever fills it out—high-income groups report higher "quality" despite having worse health outcomes in some demographics; low-income workers underreport because their baseline expectations were shaped by scarcity, not lack of objective resources. You're measuring sentiment, not condition.

Furthermore, QoL as a metric is fundamentally backward for policy. If you optimize for reported quality, the rational response is to make everything comfortable and convenient—which is exactly what produces long-term fragility. The systems that actually produce high resilience (agriculture in 1950s rural communities, manufacturing towns with multi-generational skill transfer) scored terribly on QoL metrics because they required effort, physical labor, and community dependence. By the time you've optimized for comfort, you've designed a system that collapses when conditions change.

QoL is useful for triage but useless for measurement. The problem isn't that QoL is subjective—it's that it bundles unrelated things into a single number. A 30% improvement could mean fixing one major pain point or marginally improving ten minor ones, and both are "better" in the same metric. For engineering teams, this creates perverse incentives: optimize for the easiest measurable win (the low-hanging fruit) rather than the highest-impact problem.

If you want to fix what's wrong with QoL as a metric, decompose it into specific dimensions before aggregating. Don't ask "how much better?" Ask about latency, reliability, DX friction, and error rates separately. You can always combine those later; starting with an aggregate loses the signal that tells you where to invest next.

I kept thinking about this for a few days and I think my issue is that QoL has become shorthand for 'frictionless.' There's nothing wrong with frictionless experiences — in fact, friction is almost always bad in software — but when you adopt it as your primary metric for quality of life, you end up optimized for the path of least resistance and that's where the problem starts.

The best experience I had this year was actually quite high-friction: building a home server rack from scratch because my NAS kept failing at 2 AM. It took three weekends of troubleshooting cable runs and network config, but the payoff is something no frictionless product can deliver. The 'quality' here wasn't ease — it was agency, understanding

I think about this every time I try to optimize my setup for something like video editing or code compilation — you add more tools, more automation, and eventually the friction of maintaining the system becomes worse than the problem it was solving. The metric is a measurement of perceived ease, which means it's basically measuring how good you feel about your workflow rather than whether work gets done. That's not necessarily bad, but we should be honest about what we're actually tracking.

It's a measurement problem — what does quality of life actually mean when you try to quantify

Yeah — it's basically just measuring convenience instead of meaning. That says everything and nothing at