In one line: Software now carries much of a product’s function and most of its change. Hardware and software engineers have to understand each other’s way of working, or requirements fall into the gap between them.
Core idea
In nearly every modern product, features once implemented in hardware are now done in software, and most post-launch updates are software changes. Yet software and non-software engineers often hold quite different mental models: of requirements, of what “done” means, of how change is managed, and of how long things take. The program’s exercise is to interview someone on the other side of that divide and measure the gap.
How it works
How software teams typically work:
- Version control: every change is tracked and reviewed in a shared repository.
- Continuous integration and delivery (CI/CD): each change is built and tested automatically, and packaged (for example, as a container image) for test or deployment.
- Incremental delivery: work is organized as backlogs and short cycles (see Scrum), not one big release.
- Requirements as a stream: requirements arrive continuously and are refined as the team learns, rather than being fixed up front.
Where the gaps usually are:
- Hardware engineers expect requirements to be frozen; software engineers expect them to evolve.
- “Just a software change” is rarely small once testing, integration and certification are counted.
- Software engineers often underestimate hardware lead times and the cost of physical iteration.
A useful exercise: take a device at home or work, observe how it behaves, draw a flow diagram of its features (see Functional Flow Block Diagram), and guess which are done in software and how. Even a children’s block-programming puzzle makes the point that every feature is a sequence of logic someone had to write.
In practice
Interviews across the divide often surface the same requests from both sides:
- Tell us the real requirement early.
- Treat interfaces as contracts.
- Include us in reviews before the design is set.
Engineering organizations that manage software changes with the same configuration discipline as hardware (see Engineering Change Control), while keeping software’s fast feedback loops, get the best of both.
Questions to ask yourself
- Which features of my product are implemented in software, and who owns their requirements?
- What do I wish software (or hardware) engineers understood about my work?
- How are software changes to my product controlled after release?
Connections
- Methods: Scrum, Engineering Change Control. Hardware meets software: Embedded Microcontrollers.
- Analysis: Functional Flow Block Diagram. New teammates: Teaming with AI. How to learn: Informational Interviews.
- Capabilities exercised: Connecting Across Disciplines, Inquiry, Communicating and Advocacy.
Sources
- Course interview assignment on software development; no public source.
- Schwaber and Sutherland (2020) The Scrum Guide [1]