I loved @khem 's explanation of simplicity: keep working on the code, even when it’s done. I would categorize this as an aspect of culture. Simplicity is a culture.
Also, was this the episode where you mentioned “owning the integration point”? I hadn’t heard this phrase before. Can you elaborate on what this means, and what not owning the integration point would typically look like?
Some examples of integration points:
- Top-level PCB (printed circuit board) designs (we can change electronic components and submodules as needed)
- Software build systems (we can add, remove, and update software components)
- PLM (project lifecycle management) (we write our own or use a system that can be easily extended through programming to meet our needs)
- Core application architecture (can be adapted to specifically meet our needs)
- Hosting (we can run our own servers or move applications between hosting providers as needs change)
- CI/CD (can be adapted to any task/technology)
Unless you are Apple, you need to outsource or buy some components for part of the system. Own the high-level integration points rather than the low-level details when possible. This is perhaps obvious, and what we naturally do most of the time, but engineers are funny creatures and we sometimes relish doing the low-level details when we should be giving them up focusing on higher-level pieces.
Some examples where this is not done:
- a Linux-based system PCB was designed with a parts-down SOC (system on chip) implementation, instead of using a SOM (system on module). This means the tricky high-speed (SDRAM, clock, etc.) routing is on the main board, which requires higher-end CAD tools and manufacturing processes. Because the company did not have this level of expertise in-house, it was outsourced. If they had used a SOM + baseboard approach, they could have done the simpler baseboard in-house using a tool like KiCad. If their core CPU needs changed, they could plug in a different SOM, or redesign the baseboard slightly to accommodate a new SOM, but they would not have to do the low-level CPU design work.
- a commercial, closed-source IoT platform is used in project. As time goes on, the needs of the system change, but the high-level details of the platform are fixed, so a parallel system is built to bypass the limitations of the commercial IoT platform.
- a hosted CI/CD platform is used. Once the system reaches volume production, there are new production testing needs, and they would like to leverage some of the previous CI/CD work and run the system in-house, but they can’t do that because the platform is a SaaS product.
- A PLM solution is selected that fits well with building products mostly composed of mechanical parts. The company starts manufacturing printed circuit boards, but the PLM system does not handle these types of parts very well (alternate sources based on supply, large BOMs, etc), so they end up running two systems that don’t integrate very well.
- A cloud application is developed using a lot of AWS primitives such as serverless functions, AWS-specific databases, etc. As the product scales up, the hosting costs become large, and it is realized that the application can be run as a monolith on standard Linux servers and databases much more efficiently. However, it is a complete rewrite to move it.
There are certainly valid times and use cases to outsource design, do full-custom parts-down CPU designs, host on AWS, use commercial SaaS products, etc, but as much as possible do the high-level integration in-house and use general-purpose software technologies that can be run anywhere. Intelligent partitioning of the system and good decoupling helps a lot.