Easy to start vs. easy to finish

There are many ways to classify how we do things. One way is "easy to start" or "easy to finish."

We may try to use off-the-shelf "maker" style embedded boards (Arduino or Raspberry PI) instead of a SOM (System-on-module) designed for industrial use.

An interpreted language like Python is easy to use and definitely has its place on your workstation, tooling, etc. But deploying, cross-compiling, upgrading, and maintaining a Python stack on thousands of embedded Linux edge nodes is not easy -- Go is much better over the long haul.

Skipping documentation, CI/CD, and other basic best practices is certainly quicker to start, but long-term will slow you down.

We can skip tests when writing code (often faster up front), or we can take the time to write tests as we implement features. Likewise, when we debug a problem, we can just fix the problem, or we can reproduce the problem first with a test, and then fix it to ensure it does not happen again.

Ignoring architecture up front is easier initially, but taking the time to think through architectural issues like decoupling, life-cycle management, and high-level performance, pays huge dividends long-term.

Outsourcing PCB design is easy to start, but owning the custom PCB designs in your product (especially the integration points) gives you the flexibility to easily fix, improve, and adapt.

When designing a PCB with constraints (such as high-speed or high-voltage), we can manually route the board or invest time in creating DRC rules and documentation that clearly details the board's constraints. The first approach might be quicker to get rev 1 out, but the latter makes it much easier to maintain the design over time, onboard new people, etc.

When designing hardware, we can skip creating CAD libraries, assigning house part numbers and instead hand-create BOMs. But long term it becomes very difficult to manage even a small inventory parts in the lab, let alone production. We have duplicates, things are lost, and mistakes are made.

We can do things like we've always done them (certainly easier to start), but there are new technologies, tools, and workflows that can greatly improve our productivity.

We certainly need to push hard to get to an MVP (minimal viable product), but this should be done by cutting features, not the approach. However, most people do exactly the opposite -- they want all the features up front and rather cut out the foundational investments in technology and process.

Here's the thing -- "easy to start" puts you on the path that accumulates technical debt. As time goes on, things become more complex, fragile, and difficult to manage. This approach does not scale.

"Easy to finish" puts you on the path to burn down technical debt. Over time you look for patterns and ways to simplify things. You continuously improve all aspects of the product. You select the best technologies at the time and adopt new technologies when it makes sense. This approach scales.

Starting is easy, and finishing is hard. What are you optimizing for?