Why I Still Prefer Hardware You Can Put on a Workbench

There is comfort in something you can point at

I like software. I use cloud services, write code, admire a well-designed API and have no particular wish to return to the days when every configuration change involved a serial cable and a small sacrifice to the gods of Windows drivers.

But I still prefer hardware you can put on a workbench.

By that, I do not mean every product must arrive in a beige metal enclosure with a row of terminals and a manual thick enough to stun a horse. I mean I value systems with a physical form that can be inspected, powered, measured, challenged and understood. A device you can connect to a bench supply, probe with a multimeter, look at under a magnifier and, when necessary, take apart without first opening a support ticket.

It is partly an engineering preference, but it is also about confidence. A physical device gives you somewhere to begin when the system misbehaves. You can ask ordinary, useful questions: is it powered? Is the sensor connected? Is the input actually changing? Has someone wired 24 V into a 3.3 V input and created a very expensive warming effect?

Those questions are unfashionably basic. They are also remarkably effective.

A dashboard is not the same thing as evidence

Modern technology often presents itself as a smooth stack of abstractions. There is a dashboard, an alert, a workflow, perhaps a helpful coloured blob claiming everything is healthy. Behind it may sit a sensor, a gateway, a mobile network, a broker, a database, an integration platform and a billing account quietly acquiring its own gravitational pull.

That stack can be useful. It can also make fault-finding feel like investigating a crime committed by fog.

With hardware on a workbench, you can separate the layers. If a temperature input is reading implausibly, start at the sensor and work forward. A resistance temperature detector, for example, depends on measuring resistance accurately. Cable resistance, loose terminals, poor contact pressure and the choice between two-wire, three-wire and four-wire connections all affect the answer. A dashboard cannot compensate for a wire that has fallen out of a terminal, however inspirational its user interface may be.

The physical layer has a stubborn honesty about it. Voltage is either arriving or it is not. The signal is noisy or it is not. A relay is switching, chattering or sitting there with the enthusiasm of a cat asked to fetch a newspaper.

That does not make hardware simple. It makes the problem more visible.

Repairability is a form of respect

I am increasingly suspicious of products designed to be replaced rather than understood. Some are sealed shut, dependent on a proprietary app or rendered useless when a remote service changes its mind. Their makers may call this frictionless. For the person who owns the thing, it can feel more like being gently escorted away from their own property.

A workbench-friendly design does not need to be crude. It can be compact, safe and attractive while still allowing sensible access to connectors, fuses, configuration, diagnostic LEDs and replaceable parts. Documentation matters here too. A clear wiring diagram and an explanation of fault states are not glamorous, but neither is standing in a plant room at 7am wondering whether three red flashes means “sensor fault” or “good luck”.

This matters beyond professional engineering. Disabled people are frequently expected to tolerate products that are opaque, difficult to reset or impossible to adapt. When something goes wrong, the burden falls on the user to navigate phone menus, inaccessible support channels and assumptions that the device must be used exactly as its designer imagined.

Repairable, inspectable hardware gives people options. It lets a family member, local technician or capable friend help without needing privileged access to an app or the manufacturer’s cloud account. Independence is not always doing every task alone. Often it is having systems that do not turn a small failure into an administrative expedition.

The cloud is useful, but it should not hold the screwdriver

I am not arguing that every system should live entirely offline. Remote monitoring is valuable, particularly for temperature-sensitive products, alarms and distributed equipment. Data history can reveal trends that no one would spot during a brief site visit. Alerts can prevent a bad situation becoming an expensive one.

The sensible approach is to keep critical behaviour close to the device where possible. If a temperature exceeds a safe limit, the local controller should be able to alarm or act without waiting for a cloud round trip. Network connections fail. SIMs expire. Certificates expire. DNS has one of its periodic episodes. Someone changes a firewall rule on a Friday afternoon, because apparently weekends are too peaceful.

Local control also makes commissioning easier. You can test an input, simulate an alarm and verify an output while standing beside the equipment. Then the remote service becomes an additional capability rather than the single point of truth.

That distinction matters. A dashboard should report what the system is doing, not be the only place where the system is allowed to think.

Physical things encourage better questions

Putting hardware on a workbench forces a kind of intellectual honesty. You have to consider heat, power consumption, connector strain, calibration, electromagnetic interference and what happens when someone plugs in the wrong thing. Software has failure modes too, of course, but physical constraints are wonderfully difficult to postpone into the next sprint.

They also make technology more approachable. Put a device, a sensor and a power supply in front of someone and you can show cause and effect. Change the input, observe the output, explain the chain. There is a quiet satisfaction in that which a slide deck rarely provides, even one with very enthusiastic gradients.

The best connected products combine both worlds: robust local hardware, understandable diagnostics, sensible interfaces and remote services that genuinely help. I am happy for the cloud to collect data, send alerts and make life easier. I simply want the device itself to remain something I can meet, test and, if necessary, have a firm conversation with on the workbench.

For me, that is not nostalgia. It is a preference for technology that stays legible when it matters most.