The cost of modification decides whether the system stays in use

What it is

Every modification is a cost-benefit decision: the time and mental effort of the change are immediate, certain costs; the convenience afterwards is diffuse, delayed benefit. When the cost exceeds the perceived benefit, the rational choice is not to bother — the feature still exists but stops being used. Whether a smart-environment system stays in long-term use is decided far less by how intelligent it is than by how expensive it is to change.

This explains the pervasive "ceremonial use" pattern of smart devices: enthusiastic configuration in the first month, frozen configuration thereafter, and then a quiet die-off of individual functions — not broken, just "no longer fits, and not worth fixing".

Why it happens

The cost of a modification decomposes into four segments, each shedding users:

• Finding the entry: navigation depth, which app it lives in, where it was originally configured — locating the thing to change may itself be the most expensive step.
• Understanding the existing configuration: the rule written three months ago reads like someone else's code; parameter names, units, and nested conditions all need re-decoding.
• Changing it safely: fear of breaking other interlocks — rules have invisible couplings, and touching one spot has unknown blast radius.
• Verifying it worked: no immediate feedback after the change; correctness shows only when the trigger next fires — a feedback loop measured in hours or days.

The four segments multiply rather than add; any one that is too expensive terminates the whole decision. A systematic bias compounds this: immediate cost versus delayed benefit are inherently asymmetric — ten minutes now against thirty seconds saved daily, with human discounting making "don't bother" almost always the winner.

The cumulative effect is the point: each "not worth fixing" is a small decision, but together they add up to the desiccation of an entire system. Each one looks reasonable in isolation; the aggregate is a once-evolvable system ageing into an expired snapshot.

Studying it

• Continuance research: the information-systems continuance tradition models expectation confirmation → satisfaction → continued intention; long smart-home studies record configuration difficulty and costly modification as antecedents of abandonment and feature dormancy.
• Modification-task measurement: give real users real modification tasks and decompose the four cost segments by time and drop-off point (did they give up at finding the entry, or at understanding the configuration?) — locating which segment sheds users.
• Log correlation: correlate modification affordances with usage intensity — when the modification-frequency decay curve slides before the usage-frequency curve, friction is the cause and disuse the effect; the reverse order points elsewhere (needs disappearing).

One methodological caution: self-reported "couldn't be bothered" blends cost with low perceived value, whose remedies differ entirely — interviews must probe to concrete steps ("what did you think you'd have to do first") to attribute cost properly.

Where it stops holding

• Lower modification cost is not unconditionally better. Protections against mis-edits (impact preview, confirmation, intercepting irreversible operations) are necessary costs; driving them to zero transfers the price of mistakes to the user. The target is navigation and comprehension cost, not safety cost.
• The cost threshold varies by person and moment. Enthusiasts experience configuration as fun — the cost is the benefit; most users experience it as a chore. The same interface is differently "expensive" across the two groups — evaluate by segment, not by a single standard.
• Some non-modification is correct. For functions whose need has genuinely lapsed, the right disposition is deletion, not modification — studies must count "not fixing because not needed" separately from "not fixing because too costly", or the problem is overstated.

Applying it

• Make high-frequency modifications zero-navigation: the most-touched parameters (time, threshold) editable right where results appear ("lights off at 23:00 tonight → change time"), no settings trip.
• Show the blast radius immediately on edit: "this rule drives 3 devices and is referenced by Coming Home mode" — turning "fear of breaking things" from imagination into checkable information.
• Offer a single dry run: after editing, trigger once manually to verify, compressing a days-long verification loop to seconds.
• How to check: pull the modification funnel (enter editing → understand → commit → verify) before and after shipping, watching where attrition concentrates and whether that segment's cost fell; track monthly modification rate alongside — modification rate up with error rate flat means the cost was cut in the right place.

Related

• Same group: Z7.03.1 Users must be able to adjust existing automations · Z7.03.3 When modification is impossible, users switch the whole thing off
• Nearby: Z7.04 Long-term evolution · Z5.04 Ways of expressing orchestration
• Search terms: continuance · maintenance burden · customisation cost · smart home abandonment