Why "We'll Fix It in Software" Should Make Hardware Engineers Nervous

“We’ll fix it in software” is one of those phrases that can be either reassuring or faintly alarming, depending on who says it and what, precisely, has gone wrong.

Sometimes it is entirely reasonable. A device ships with a conservative control algorithm, gathers field data, and receives a software update that improves battery life or makes an interface less baffling. Excellent. That is one of the genuine benefits of connected products.

But when the phrase is used to wave away an awkward hardware limitation, it should make an engineer sit up a little straighter. Software is powerful. It is not a small, tireless civil servant capable of issuing permits to ignore physics.

Software can correct errors, not create information

The fundamental limitation is simple: software can process a signal only after the hardware has captured it. If the sensor is badly positioned, the analogue front end is noisy, or the measurement circuit lacks sufficient resolution, no amount of clever code can recover information that never arrived.

Take temperature measurement. A sensor mounted close to a heat-generating processor may report a temperature influenced by the processor, the enclosure, airflow and the thing it was actually meant to measure. Filtering the reading may make the graph look calmer. It does not make the sensor more representative.

A moving average can reduce random noise, for example, but it also delays the response. In a slowly changing room, that may be acceptable. In an overheating cabinet or a thermal process with a rapid excursion, it may mean the alarm arrives politely after the important bit has happened.

There is a related trap with calibration. Software can apply a calibration offset or a more sophisticated correction curve, provided the underlying device is stable and the error is understood. It cannot permanently compensate for a sensor with poor thermal contact, moisture ingress, component drift outside the characterised range, or a reference voltage wandering about like it has misplaced its keys.

Timing is hardware too

Engineers often discover this problem when a prototype is converted from a bench-top success into a product that must operate reliably for months.

Consider a microcontroller reading an analogue sensor. The analogue-to-digital converter needs enough acquisition time for its sampling capacitor to charge through the source impedance. If the sensor output is buffered badly, or not buffered at all, readings can be wrong in a repeatable and rather convincing way. The software team may then build increasingly elaborate correction logic around a measurement artefact created by circuit design.

Similarly, software cannot make a slow sensor physically respond faster. It can estimate a probable current value from a thermal model, but that estimate depends on assumptions about ambient conditions, airflow, thermal mass and installation. Those assumptions may be decent in a controlled test and rather less decent once someone mounts the product somewhere unexpected, which they eventually will. People are remarkably inventive when given mounting brackets.

Real-time behaviour has hard boundaries too. If an interrupt is delayed because the processor is busy, a packet is lost because a buffer is undersized, or a power rail dips during a radio transmission, code may mitigate the consequences. It cannot retrospectively service an event it missed.

The cost of moving a hardware problem into code

Even where software can compensate, it may not be the best place to do so.

Every compensation algorithm adds requirements: more test cases, more documentation, more version control, more support work and more opportunities for one device revision to behave differently from another. A simple hardware improvement can sometimes remove a remarkable amount of software complexity.

This matters especially in products with long lives. A workaround that seems harmless during development becomes institutional archaeology three years later. Someone finds a mysterious coefficient, asks why it exists, and discovers it is holding together a design decision made during a Friday afternoon meeting in 2026. Nobody remembers the meeting. Everyone remembers the coefficient, usually with feeling.

There is also a safety and assurance question. If a measurement affects an alarm, control loop or compliance record, the correction must be demonstrably valid. “The dashboard looked about right” is not a validation strategy, however warmly it may be delivered.

A better question to ask

Rather than rejecting software fixes outright, hardware engineers should ask: what kind of problem is this?

If the issue is a policy decision, user workflow, protocol behaviour or algorithm tuning, software may be exactly the right answer. It is adaptable, updateable and often cheaper than revising a board.

If the issue concerns signal integrity, sensor placement, electromagnetic interference, power stability, heat flow, mechanical tolerance or component limits, begin with the physical design. Measure the failure mode. Identify what information the system genuinely has. Then decide whether software is a correction, a guardrail or merely a decorative blanket over a draughty window.

The best systems use hardware and software as partners. Good hardware gives software clean signals, enough headroom and predictable failure behaviour. Good software monitors plausibility, detects faults, manages uncertainty and makes sensible decisions when conditions are imperfect.

That division of labour is not glamorous, but it is kind to the people who must build, test, support and eventually understand the product. And it saves everybody from discovering, after the enclosure has been moulded and the boards have been ordered, that software has many talents but still cannot persuade a badly placed sensor to be somewhere else.