Field Software Fails by Abandonment, Not by Bugs

There is a particular kind of project post-mortem that never mentions a defect.

The application works. It passed testing, it deployed, it is available on every device in the fleet. Six weeks later usage has collapsed, the data coming back is patchy, and someone in operations is quietly reconciling paper again. Nothing broke. People simply stopped.

Field software fails this way far more often than it fails technically, and the causes are consistent enough to design against.

The device is not the constraint. The conditions are.

Field applications are specified in meeting rooms and used at wellheads, on scaffolding, in depots and in the rain. That gap accounts for most abandonment.

The interaction that tests fine at a desk is being attempted one-handed, wearing gloves, in bright sun that makes a low-contrast interface unreadable, by someone whose other hand is holding equipment. A dropdown with fourteen options is a reasonable control at a desk and an unusable one on a ladder.

Our energy field work uses a floating keypad and attribute-level image capture for exactly this reason. Not because it is novel, but because the standard numeric input assumes a free hand and a stable surface, and the site provides neither.

The test we apply is simple: can this be completed one-handed, outdoors, wearing gloves, with no signal? Most enterprise interfaces fail it, and the failure is invisible in a demo.

Connectivity is not a degraded state

Field software that requires a network gets abandoned in the first week. Depots, yards, rural routes, basements and construction sites routinely have no signal, and a form that stalls on submission has taught its user that it cannot be relied on. That lesson does not get unlearned.

Offline-first is a starting assumption, not a resilience feature added later. Everything captures locally and reconciles when a connection returns — and conflicts are surfaced rather than silently resolved, because a surveyor who finds their reading quietly overwritten stops trusting every other number in the system.

Retrofitting this is close to a rewrite. The data model, the sync strategy and the conflict semantics all change. It is much cheaper to decide at the start.

Every keystroke has to buy something

A field worker's willingness to use software is finite and it is spent per interaction. If a screen asks for information that could have been inferred, defaulted, or captured from a photograph, it is spending that willingness on nothing.

The question for every field is what it saves. Does it prevent a return visit? Settle a dispute? Trigger a reorder? A field that exists because someone might want the data eventually is a field that will be filled with rubbish within a month, and rubbish data is worse than none — it gets trusted.

Catch the problem at the asset

An anomaly found in a report next week costs a second site visit. Found at the point of capture, while the operator is still standing at the asset, it costs thirty seconds.

This is what an exception framework is for: bounds checked at entry, so a reading that cannot be right is queried immediately rather than becoming a data quality issue for somebody else. It is also the cheapest quality control available in field operations, because the person who can resolve the discrepancy is right there.

Photograph the thing that will be disputed

Image capture attached at attribute level rather than to the visit as a whole is a small design decision with disproportionate value. Months later, in a disagreement about what was delivered or what condition an asset was in, the photograph is the record. A gallery of thirty images from a site visit is not evidence. One image attached to the specific reading is.

The measure

The metric that matters for field software is not uptime and it is not defect count. It is whether people are still using it in week six, once the novelty and the mandate have both worn off.

That number is knowable early, and it is worth watching from the first pilot — because when it starts falling, the cause is almost never a bug.

---

iLeaf builds survey-driven field applications for construction and infrastructure, energy and logistics — including AIMS, built for CALM IPSUM Group LTD to inspect water-authority assets across the UK: pipe bridges, CSO chambers, penstocks and detention tanks, captured offline by field crews and synced when a signal returns.