There are many types and levels of modular design. Daedalus designers and engineers across disciplines are always thinking about where modularity can add value. Highly modular designs are generally more complex, but can be cheaper or more desirable for customers if they have a wide set of requirements or use cases. Highly integrated designs, on the other hand, can be easier to use and quicker to design, but can be more expensive in the long run and may have a more limited set of capabilities.
There are many ways to take advantage of this idea. Customer-facing modularity involves designing swappable or interconnected modules for high user customizability. Design modularity involves sharing components or subsystems across different designs or products to achieve greater economies of scale and more streamlined manufacturing processes like assembly and testing. Common or industry-standard interfaces such as Bluetooth, USB-C, DIN rails, etc. can greatly increase customer modularity with little overhead. Even forms of modularity that require engineering or technician intervention can provide substantial value. If a certain subsystem of a design (such as a circuit board) requires additional engineering design work or technical expertise to serve a different purpose, it is still easier and more cost-effective in the long run if that subsystem was designed with clean, well-documented interconnects to the rest of the system.
However, increased modularity generally means increased development costs and design compromises at the point where the subsystems connect. A modular device platform needs a single connector or interface that can support the requirements of every module, whereas a purpose-built design only has to satisfy a single set of requirements, allowing for a much leaner, more efficient, and more reliable design. For example, Apple justifies its anti-modular hardware philosophy by arguing its products are more reliable than those of its competitors because there are fewer connectors between parts, where each of these connections represents another potential point of failure. (Of course, this design philosophy also makes its products more difficult to service and repair, a drawback which is actually another benefit for Apple.)
Over time, software has evolved toward greater modularity, as seen in mobile apps, APIs, and abstraction layers, in contrast to consumer hardware. The numerous examples of modular hardware failures such as Motorola’s Moto Mods, Google’s Project Ara, the Nissan Pulsar NX, and broader trends like the steady reduction of ports on consumer electronics reflect a market that is increasingly wary of hardware modularization. The cost and design overhead related to incorporating more modularity is naturally much lower when the interconnects between modules consist of lines of code rather than expensive mechanical or electrical parts.
Also, customer-facing modularity specifically requires a lot of customer buy-in. People must be heavily engaged with the product or device in order to take advantage of its customizability. Most users want to buy something for a particular purpose and have it instantly solve an issue without a learning curve. For devices where users are already experts (industry-specific devices such as medical devices or industrial safety devices), more modularity can be more attractive. Designing a modular platform is also much more “all-or-nothing”, as it may require the users to buy into an entire system rather than a purpose-built single device, which could be especially difficult if other platforms already exist. Think, for example, of competitors to LEGO. MEGA BLOKS are much harder to sell to someone who already owns a few LEGO sets.
These tradeoffs look different depending on what you’re building and how. The considerations a mechanical engineer weighs when designing a modular enclosure or chassis are fundamentally different from those an electrical engineer faces when partitioning a PCB into swappable subsystems. They differ again from the architectural decisions a software engineer makes when structuring a codebase for long-term flexibility. In future posts, we will explore how modularity plays out within each of these disciplines: what it looks like in practice, where it tends to pay off, and where it quietly introduces more problems than it solves.