Costs compound with device count, while each device's cost looks tiny
Aliases: cost scaling · configuration burden
What it is
The three costs of invisible computing — clueless faults, unreadable states, unbounded systems — are each small at the level of a single device, small enough to be invisible at purchase. But the costs do not settle per device: with every added invisible device, the system's total cognitive debt grows combinatorially — two devices share 1 relationship, ten share 45, and relationships (what triggers what, what depends on what, whose data feeds whom) are precisely where the costs occur.
The purchase view and the use view misalign here: each device arrives carrying only its own small cost, and the user never makes a decision about "the 45th relationship" — yet the bill eventually arrives addressed to the relationship total. The widespread smart-home experience — "every device is fine, the whole is unmanageable" — is that misalignment playing out.
Why it happens
Why does accumulation outrun linearity? Three multipliers.
Interaction path count. Diagnosis and control cost scales not with device count but with candidate symptom-device pairings. N devices give N possible fault sources, and the exclusion chain for one anomaly grows with N — "why didn't the light come on" used to have one source (the switch) and now has every sensor, rule, and automation that might trigger it.
Mental-model maintenance. Each device levies an "update tax" on the user's model. A single-device model survives on occasional use; a multi-device model's correctness also depends on remembering relationships — which automations changed, what connects to what — information no daily use ever reinforces, held only from configuration day. Decay is guaranteed.
Small probabilities summing. A single device's failure rate may be one percent a year, but the user experiences not rates but intervals between events: in a forty-device home, failure is not an exception but ambient weather. The system shifts from "usually fine, occasionally fixed" to "always something broken" — while each fault's diagnostic cost simultaneously grows with N. Two growths multiply.
Studying it
- Scale-comparative studies: recruit households stratified by device count (single digits / teens / dozens), comparing fault frequency, diagnostic duration, abandonment rates, and burden measures. That scale is a dominant complexity variable recurs across long-term smart-home deployments.
- Configuration memory decay: at varying intervals after configuration, test users' recall of their own automations against logs, quantifying the update tax.
- Abandonment trajectories: trace users who go from "everything automated" to "switched it all off", identifying the triggering event — typically a fault spanning several devices, almost never a single-device problem.
One methodological caution: cross-sectional comparisons admit self-selection (tinkerers own more devices); where possible, track the same household longitudinally. And keep device count and rule count separate — the multipliers live in the rules, not the hardware.
Where it stops holding
- What compounds is invisibility's cost, not device count per se. A room full of conventional appliances — visible, crisply bounded — shows quantity effects too, but each unit's boundary model is intact. The multipliers here operate only when state, clues, and boundaries are unreadable.
- Platform-level management flattens the curve but not to zero. A unified dashboard turns "walk the devices" into "read one record", converting a linear multiplier into a constant — provided users trust the state the dashboard itself reports.
- Below a threshold this entry does not apply. With three to five devices and no automations, relationships remain countable on one hand, and small per-device costs really are small. Do not extrapolate to every multi-device scenario.
Applying it
- Make relationships explicit as part of any scaling decision: before a household crosses roughly ten devices, provide a viewable map of its automations. Visible relationships directly hedge the multiplier.
- Install scale thresholds: notify on count milestones ("you now have 30 automations") with a review-and-prune entry point — the decision moment for accumulated cost should not exist only at purchase.
- Default to subtraction: proactively suggest retiring automations that have not fired in months; relationship decay (an automation long irrelevant) is stealthier than device failure.
- How to check: track two numbers — the user's automation rule count, and how many of those have not fired in 90 days. The stale share rising with scale is the cognitive debt, invoiced.
Related
- Same group: Z1.05.1 When invisible systems fail, users lack the clues to localise the fault · Z1.05.2 Users cannot tell whether a device is still sensing or running · Z1.05.3 Invisibility erodes users' sense of the system boundary
- Nearby: Z1.06 Device ecosystems and coordination · Z7.04 Long-term evolution
- Search terms:
smart home scaling·configuration burden·automation abandonment