Modularity is mostly about upgrade paths

People often talk about modularity as if it were a style preference.

I do not usually think about it that way. In systems work, modularity is mostly about what can change without forcing everything else to change with it.

That sounds simple, but it is the question that sits underneath a lot of good and bad engineering decisions. When a program lasts for years, the hardware changes, the tools change, the team changes, and sometimes the mission framing changes too. A design that only works when all of those things stay still is not really a design; it is a snapshot.

The practical value of modularity is that it gives the system an upgrade path.

In receiver work, that can mean isolating the boundaries between algorithmic logic, hardware acceleration, RF-front-end assumptions, and the host-side software that consumes the outputs. A clean boundary does not eliminate the need to redesign, but it does reduce how much churn leaks into unrelated parts of the system.

That matters for more than code hygiene.

If a hardware block needs to change, I want the rest of the software to feel as little pain as possible. If a new signal mode arrives, I want a clear idea of which abstractions hold and which ones were only pretending to be abstractions. If a new team member joins, I want the system structure itself to teach them something instead of forcing them to rediscover the whole design socially.

Good modularity also has a negative test: it should make accidental coupling easier to see.

That is part of why I like explicit interfaces and architectural views even on teams that are perfectly capable of “just building it.” Once a system gets even slightly large, undocumented coupling is one of the easiest ways to lose years of future flexibility in exchange for a short burst of present convenience.

None of this means every boundary should be formalized to death. That can become its own failure mode. The point is not ceremony; the point is preserving room to change the parts that will inevitably need to change first.

So when I say I care about modularity, what I usually mean is this: I care about being able to update the system without paying the full integration cost every time a single part evolves.