Why Hardware Companies Keep Underestimating Software Systems Engineering

There is a recurring pattern in hardware-centric organizations that is consistent enough to qualify as a structural failure mode: a company with deep mechanical and electrical engineering expertise launches a product with growing software content, and the software team chronically underdelivers against schedule. The instinctive diagnosis is that the software engineers are slow, or that estimation is poor, or that scope creep was badly managed. The actual diagnosis is almost always different. The organization never built the systems engineering discipline — the requirements, interface definitions, and traceability infrastructure — needed to make software development predictable in the first place.

This is not a critique of any specific company. It is a pattern that repeats across automotive Tier 1 suppliers, aerospace integrators, and industrial equipment manufacturers, in programs ranging from ADAS controllers to flight management computers to industrial servo drives. The specific failure modes vary. The underlying cause is consistent.

What “Underestimation” Actually Means

When hardware organizations say they underestimated software, they usually mean they underestimated lines of code, developer headcount, or calendar months. Those are symptoms. The actual underestimation is structural.

Mechanical and electrical engineering have properties that make informal coordination workable at moderate scale. Physical interfaces are visible, dimensioned, and toleranced. Change propagates in ways that are bounded by geometry and physics. A mechanical engineer looking at an assembly can identify most of the interface dependencies without a formal interface control document, because the interfaces are physically present in the artifact.

Software and firmware have no equivalent property. A 200,000-line embedded codebase can contain thousands of implicit interface assumptions — state machine preconditions, timing dependencies, shared memory layouts, communication protocol versioning constraints — none of which are visible in the artifact itself. The code runs or it doesn’t. When it doesn’t, finding out why requires knowledge that should have been encoded in requirements and interface documents but frequently wasn’t.

Hardware engineers managing software programs for the first time typically apply hardware estimation heuristics: add features incrementally, budget time proportional to apparent complexity, rely on engineers to self-identify blockers. These heuristics fail in software because the cost structure is different. The most expensive bugs in embedded software are integration bugs — failures that only surface when subsystems interact. Integration bugs are prevented upstream by requirements and interface discipline, not by adding engineers downstream.

The Automotive Tier 1 Pattern

The automotive supply chain provides the clearest case study because software content in vehicle systems has grown faster than most programs anticipated. A Tier 1 supplier that built its reputation on brake actuators or transmission hardware now routinely delivers the embedded software for that hardware as part of the module supply contract. In many cases, the software is now the harder engineering problem.

What typically happens: the hardware design schedule drives the program. The PCB layout, component qualification, and EMC testing have hard deadlines tied to OEM build events. Software is scheduled to complete in parallel, often with the implicit assumption that firmware is largely straightforward configuration work on top of a standard AUTOSAR stack. That assumption is wrong.

AUTOSAR does provide standardized basic software, but the application layer — the functional safety logic, the diagnostic protocol implementation, the calibration interfaces, the CAN/LIN/Ethernet communication matrix — is bespoke to each program. Each of those layers requires explicit requirements before it can be designed. In practice, software teams frequently receive incomplete system requirements and no formal interface control documents from the OEM, write code against verbal agreements and email threads, and then spend the back half of the program trying to reconcile what was built against what the OEM actually needed.

The ASPICE framework exists precisely to address this. ASPICE Level 2 requires that software requirements be derived from system requirements, that interfaces be explicitly specified, and that traceability exist from system level down to software unit. The problem is that achieving ASPICE compliance is treated as a documentation exercise by organizations that lack the underlying process. Traceability matrices are populated after the fact. Requirements are written to describe what was built, not to specify what should be built. The audit passes. The program still overruns.

The Aerospace Integrator Pattern

Aerospace programs operate under more stringent certification requirements — DO-178C for airborne software, ARP4754A for systems development — and yet the same pattern appears, particularly at integrators managing large supplier networks.

The failure mode here is at the system boundary. An aircraft integrator defines system-level requirements for, say, a flight control computer. Those requirements specify functional behavior at the aircraft level. They do not fully specify the software-to-hardware interface: interrupt latency budgets, memory map constraints, power sequencing behavior, sensor data validity rules. That specification gap gets filled by the supplier’s interpretation, or by tribal knowledge from the previous program, or not at all.

When integration testing begins and the flight control computer behaves unexpectedly under edge-case loading conditions, the root cause frequently traces back to an interface assumption that was never written down. Finding and resolving it requires a formal change control process, potentially a software re-verification cycle, and schedule impact that was not in any program budget.

The deeper problem is organizational. Systems engineers at aerospace integrators are expert in aircraft-level functional decomposition. They are less consistently expert in hardware-software interface specification, because for much of aviation history, software was a smaller fraction of system complexity. The proportion has shifted dramatically. The organizational expertise has not shifted at the same rate.

The Industrial Equipment Pattern

Industrial equipment manufacturers — servo drive companies, robotics OEMs, heavy machinery controls suppliers — face a variant of this problem that is less visible because their regulatory environment is less prescriptive than automotive or aerospace.

In industrial equipment, software underestimation typically manifests as field failures. A motion control system is commissioned at a customer site. Under a specific combination of load profile, network timing, and firmware revision, the controller exhibits intermittent faults. Reproducing the fault in the lab requires weeks. Fixing it requires tracing a failure mode through a system where the interface between firmware, FPGA logic, and motor drive hardware was never formally specified.

Industrial companies in this situation have usually made a reasonable business decision: the overhead of formal requirements and interface documentation is hard to justify when the product line is small and the engineering team all worked on the previous generation. The problem surfaces when the team grows, when the product line expands, or when a key engineer leaves and the tribal knowledge leaves with them. At that point, the cost of the missing documentation is paid all at once.

What Organizational Changes Are Actually Required

The tooling question comes second. The organizational question comes first.

Software systems engineering must be a role, not an activity. In hardware-dominant organizations, systems engineering is typically practiced by mechanical or electrical engineers who manage requirements and interface control at the hardware level. Software requirements are often treated as the software team’s internal problem. Closing the gap requires engineers whose specific job is to define software requirements from system requirements, own software interface control documents, and maintain traceability from system level to software. This role is distinct from software architecture and distinct from traditional systems engineering. It does not exist in many hardware companies.

Interface control documents must be owned, not filed. An ICD that is written once at program kickoff and never updated is not a systems engineering artifact — it is a liability. ICDs need an owner who is responsible for keeping them current as system design evolves, and a process that gates design decisions on ICD updates. This sounds obvious. In practice, ICDs at hardware-dominant companies are usually owned by whoever wrote them, which means they are owned by whoever had bandwidth at kickoff, which means they are owned by no one.

Requirements must be written before code is written. This is the most contested point because it feels like it conflicts with agile development practices. It doesn’t. The conflict is between writing requirements at the wrong level of abstraction and writing them at the right level. Agile user stories are not a substitute for software requirements specifications. A story that says “as a calibration engineer, I want to update sensor scaling factors without a firmware reflash” does not specify the interface, the storage format, the validation logic, or the failure behavior. All of that needs to be specified somewhere before it can be implemented consistently.

Estimation must account for integration, not just implementation. The most reliable predictor of software schedule overrun is integration complexity that was not accounted for in planning. Hardware organizations estimate software as if implementation complexity is the binding constraint. It rarely is. Integration complexity — testing across hardware variants, resolving interface ambiguities, handling edge cases that only appear in system-level test — is typically where programs lose months. Estimation that does not model integration risk is systematically optimistic.

How Modern Tooling Can Help — And What It Can’t Fix

The practical overhead of maintaining requirements traceability, interface control documents, and change impact analysis has historically been severe enough that many organizations rationally decided the overhead cost more than the discipline was worth. That calculus is changing.

Tools that treat requirements as a connected graph rather than a document hierarchy make it possible to trace a system requirement through software architecture to software requirements to test cases without a manual spreadsheet exercise. AI-native platforms — those built around structured models from the ground up rather than retrofitting AI onto document management — can identify gap coverage, flag interface changes that have downstream requirements impact, and generate structured requirement drafts from natural language inputs. Flow Engineering is one platform doing this work in industrial and embedded systems contexts: requirements are modeled as nodes with explicit relationships, not as rows in a Word document, and AI assistance is woven into the process of authoring and maintaining traceability rather than bolted on as a search interface.

What tooling cannot fix is an organization that does not assign ownership for software requirements work, does not gate design progress on requirements completeness, and does not staff software systems engineering as a distinct capability. A better tool operated by an underfunded, understaffed requirements process produces better-formatted requirements that are still incomplete, stale, and not traced to tests.

Honest Assessment

Hardware companies underestimate software systems engineering because their mental models of engineering complexity were formed around physical artifacts, and those models transfer poorly to software. The consequences are program overruns, integration failures, and field defects that trace back to interface assumptions that were never documented.

Fixing this requires naming the problem accurately. It is not a software problem. It is a systems engineering problem that manifests in software because software is where all the unresolved interface ambiguity lives at the end of a program. The fix is upstream: explicit requirements, owned interface documents, staffed roles, and estimation models that account for integration.

The organizations that have closed this gap — and some have — typically did it after a program-level crisis forced the investment that normal schedule pressure would never justify. The gap is closable. The cost of closing it is lower than the cost of not closing it. Most hardware companies will learn that the hard way.