As somebody who was blessed to enjoy a career in both mechanical hardware and software engineering, it’s nice to appreciate the philosophical design similarities between these domains. In hardware I learned the value of modularity and commonality. In software, achieving a high level of modularity, separation and cohesion is generally a good thing…

  • In hardware I learned the value of modularity and commonality.
  • Big hardware modules can be broken into smaller modules with core fundamental functions that can be reused across multiple parent modules.
  • There are interfaces that defines the boundaries between the core hardware modules, but in general, they do not need to have any knowledge of where they are going to be used, only that they are designed to perform core specific functions and do it really well with extremely high reliability.
  • The design of hardware interfaces are very important, multiplying the number of interfaces to achieve more common reusable modules can lead to more upfront development and design complexity, so a careful balance must be achieved how much seams you would like to introduce into the hardware design.

  • Core hardware modules are likely be reused across multiple larger modules and even across multiple product lines. It can significantly reduce the cost of development and delivery. The parts and components that comprises these smaller modules enjoys the benefit of scalability, and putting them together in mass volume presents a lot of opportunities for build optimizations.

  • In software, achieving a high level of modularity, separation and cohesion is generally a good thing.
  • In a clean software architecture, modules must be designed with a clear purpose in mind relative to the entire system. The parts of these modules must work cohesively as a unit, so if one needs to reuse or eliminate a module, there’s very clean separation and coupling that would minimize it’s portability or disposal.
  • We purposely develop clean interfaces on modules that defines how they are intended to be consumed or used. Well designed interfaces promotes reusability and testability along the seams of your software system boundaries.
  • By the same contrast in hardware design, introducing more interfaces increases upfront development and design complexity, so a careful balance must be considered.
  • Low level modules in software can be compared to the hardware reusable core modules described above. Hardware interfaces relies on a contract on how they are supposed to be integrated, and these contract also exist in software through abstractions. The consumer must generally not be concerned about implementation details of what they are consuming.
  • The lower the modules, the more granular their intended functions are. Like in hardware, they have no knowledge of and generally are not concerned of how or where they are going to be used, only that they are designed to perform core specific functions and do it really well with extremely high reliability.

It’s interesting to observe how engineers think similarly on completely different domains, and it’s nice to appreciate its beauty from within.