Platform Thinking

[cbrake]

Are your processes proactive or reactive?

There are two ways to implement a process.

The traditional way is as a check to make sure people did everything right. This could be required documentation that is written after a project is finished, a separate QA department that runs tests after each release, or various certifications like UL, FCC, CE, etc. There are certainly times when things like this are necessary; however, writing documentation after the fact is never much fun, and dealing with failure reports from the QA department is not all that pleasant, and the FCC testing facility has been called “the house of pain.” We’ll call this the “reactive” process approach.

An alternative approach is the “proactive” process. Structure your documentation efforts as part of the development process – as a way to help you think and as a vehicle for collaboration. QA can also be implemented proactively as automated tests that are run during development.

Proactive processes focus on well-designed tools that help the people doing the work get it right vs. tools that help managers who oversee the work. Proactive process tools are well-designed, fast, and a pleasure to use.

Think what could happen if UL focused on providing KiCad templates and DRC rule sets for various high-voltage design scenarios that would help engineers do their work instead of a bureaucratic morass that is very painful and expensive to work through. The first approach encourages innovation, whereas the current approach greatly hinders it.

Some reactive processes are necessary, but where is your focus? The more you can shift your processes from reactive to proactive, the better off you’ll be. This is what Platform Thinking is all about – building YOUR Platform.

[cbrake]

Use a headset optimized for calls

One thing most of us do routinely is voice calls or video conferencing. For this to work, each party needs to have a microphone and a speaker.

The simplest setup is to use the microphone and speaker built into your phone, laptop, or car. Sometimes this works pretty well.

But, often we are environments where this is background noise. Simple microphones, especially those some distance from our mouths, cannot discern background noise from our voice. AGC (automatic gain control) algorithms tend to amplify any sound to capture your voice. The most baffling scenario is those walking through a busy airport holding a phone in front of them in speakerphone mode. Another disruptive problem is echo which sometimes occurs when using a laptop mic/speaker for video conferencing. Trying to talk when your voice is being echoed back is nearly impossible.

Conversely, our ears are very good at differentiating what we want to hear from local background noise. Our brain and ears are very sophisticated instruments and include features such as using the time delay and intensity difference between each ear to pinpoint a source, selective focus, frequency tuning, adaptive processing, etc.

Some headsets attempt to block out background noise to the microphone. The most effective ones have a direction microphone located very close to your mouth (on a boom), or a microphone array and DSP processing. Two examples I’ve used are the Plantronics - Voyager 5200 (Bluetooth) and the Sennheiser SC 160 (USB).

There are likely many other good options. I use the Plantronics with my phone and the Sennheiser with my computer. Both are very effective at blocking out background noise and I’m sure there are many other effective models.

The result is whomever I am communicating with can clearly hear what I am saying without being distracted by background noise in my environment. This makes me more effective.

Some headsets have noise noise cancellation for the speakers. This is very nice for deep work when we are trying to focus and need to block out all sounds other than perhaps some music. But they are of marginal use during a call because our ears are already pretty good at focusing on one sound and during a call we have the discussion to focus on.

Consider having separate headsets for deep work (noise-cancelling speakers) and calls (noise-reducing microphones) as part of YOUR Personal Platform. This may seem like a minor thing, but the small things add up. Using a good microphone is a courtesy to those listening to us. It is a courtesy to the entire group on the call that our background noise is not interrupting the call. It is professional. It shows we care about others.

For more discussion and review, see this thread.

[cbrake]

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?

[cbrake]

Goals vs. Systems

“You do not rise to the level of your goals. You fall to the level of your systems.” – James Clear, Atomic Habits

Goals and vision are important, but we also need a way to get there.

[cbrake]

Inbox zero

Thanks to a nudge from Khem, I’m back to Inbox-zero.

The big question is what to do with emails that need action or have valuable information in them? Some put them in a special folder. Others tag them. Others forward them to lots of people.

The best solution is to move the action or information to another system such as a project ticketing system, or Workflowy (my personal notes system). I then archive the email and dig it out of the archive if I need to reply later.

Email is a great notification system, but it does not work very well at the following:

• collaboration
• knowledge capture
• workflow

Find other solutions for the above such as:

• Github/Gitea/Gitlab issues, projects, wikis, etc.
• Markdown in Git is a great way to capture knowledge from emails
• Trello
• Personal notes system

Collaboration, knowledge capture, open access to knowledge, and workflow are key components of YOUR Platform. Getting information out of email is critical, and following an Inbox-zero policy is a great way to help make this happen.

[cbrake]

What is your most important tool?

Your editor? Your CAD tool? Your 2GHz oscilloscope? Your phone? Your computer?

In the information age, we are flooded with information and opportunities.

Many of the problems we solve are ones we’ve never seen before, or at least not very often.

Most of us have more to do than we can ever hope to get done in multiple lifetimes.

We are exposed to way more knowledge than we can ever fit in our finite memories. Therefore, a tool to efficiently capture, organize, and find your personal knowledge may be your most important tool.

If we figure out something, we can make a note so we don’t have to figure it out again the next time.

If we repeatedly do something that requires multiple steps, a checklist can make this easier.

If we learn something valuable, a note makes this useful in the future.

Creating notes encourages reflection.

With a good notes system, we can organize and prioritize what we do.

Over time this helps build a picture or model of what we know and have experienced. This model helps us leverage what we have done in the past in the future.

There are many good notetaking tools and methods (Notion, Workflowy, Logseq, Bullet Journal, etc.) so there is very likely one that will fit you. Some things I look for:

• low friction to use
• stores text and images
• can be used on multiple mobile and desktop platforms
• can export the information so that it can be moved to another system if necessary
• has a stable history and likely future – something you can use for 5-10+ years
• easy to share information with others
• and most importantly – you own the information and can take it with you. IE, don’t store your personal knowledge base in your employer’s MS Teams OneNote app.

Workflowy has been perfect for me, but there are lots of other good options.

Over time your personal notetaking tool becomes a valuable knowledge base that you can take with you anywhere you go – part of YOUR Personal Platform.

[cbrake]

Personal vs. collaborative documentation

Yesterday, we discussed the importance of a personal note-taking tool. We can also extend this concept to a team or company using Wikis, Markdown in Git, shared Google Docs, etc.

Collaborative documentation is very valuable – IF you can get group participation. Over the years at various companies, I’ve set up Wikis as collaborative documentation efforts. Most of them resulted in only me contributing. Group initiatives like this need to come from the top, otherwise there is very little incentive for people to contribute. As a result, I’ve pretty much given up on Wikis for small teams/companies – it is nearly impossible to get momentum and maintain the information. This is sad because so much knowledge is lost and effort wasted as the same things are rehashed, relearned, and re-communicated.

As a result, I now focus primarily on:

• My own personal notes system.
• Markdown in project Git repos

If I’m going to be the only one creating and reading notes, it may as well be in my own personal notes system which is most convenient for me.

For project documentation, this is best maintained in the Git repo as close as possible to the source code or design files. There it has a better chance of documentation being maintained if it is worked into the PR workflow and review process.

In the course of product development, documentation is the hardest deliverable to produce because its effects are hard to measure. Initially, the product still functions without documentation. Documentation costs short-term but produces compounding gains long-term. It is an investment in the future. If your team or organization is not interested in making this investment, you can always make it personally.

[cbrake]

Keeping commitments

When we commit to something, do we follow through? How do we get better at this when we always have more to do than time to do it?

The thought came recently that it probably starts with keeping commitments to ourselves, which is the essence of self-discipline. If we can’t keep promises to ourselves, likely we won’t keep them to others either.

If we plan to get up at 6 AM, do we?

If we plan to walk every day, do we?

If we plan to work on something today, do we block out the time and make it happen?

Seemingly simple things, but important and sometimes hard in this busy life.

If we can’t do the small things, we’ll likely not succeed in the bigger things.

This is foundational in Platform Thinking – at the personal, group, or organization level. If you do the small things right, this will enable you to do the big things.

[cbrake]

Abstractions and Platforms

I’ve come to appreciate the Go communities advice on abstractions.

Avoid creating abstractions prematurely. Every abstraction has a cost, and often duplicated code is simpler and easier to maintain than a premature abstraction.

Don’t take DRY (Don’t Repeat Yourself) to an extreme. It is perfectly fine to duplicate code several times and only create an abstraction once you see a clear pattern and understand better the problem the abstraction is solving.

For instance, in Simple IoT, we implemented a number of subsystems (rules, modbus, 1-wire, etc.) before we noticed a pattern – all of these systems needed lifecycle management, which is very tricky to get right. So it made sense to create a client abstraction that handled lifecycle in one place. But it was not clear what we really needed until we had implemented several subsystems.

Follow the YAGNI (You Ain’t Gonna Need It) principle – only create abstractions when you need them, not for hypothetical future use cases.

The same applies to platforms.

Other than avoiding architectural pitfalls and selecting the wrong technology, focus on building out YOUR Platform to solve your current needs, not your future needs. This is one of the best ways to know if your architecture and technology are right.

Platforms for the sake of platforms are detrimental and counter-productive – kind of like the IT department that loses its focus that they are there to serve the business needs and becomes a barrier to getting things done. They must serve the business goals, not themselves.

A platform in itself provides no value if you are not shipping something of value.

The same can be said of any supporting role or metric – finance, performance, etc.

If you are not shipping (internal prototypes and test versions count as shipping), nothing else matters.

[cbrake]

Lifecycle management in dynamic systems

One of the hard parts of dynamic systems is the lifecycle management of various bits of running code.

It is easy to create stuff, but are you cleaning up properly when things disappear or change?

We can order these in difficulty:

• Create something: (easy)
• Delete something: (hard)
• Change something already running: (very hard)

On the surface, this looks easy – what is the big deal, right?

But we soon realize differently. Have you ever heard of memory/resource leaks and race conditions? Even worse, code that we don’t know is still running.

Implementations usually start simple – no problem.

But the scope grows, the system becomes more dynamic, and we start to scale. Scaling requires concurrency. Concurrency is hard, but when the system changes while running, concurrency gets really hard.

This is the nature of IoT systems – because they reflect the real world, and the real world is always changing.

[cbrake]

Dates in filenames

One of the most common labels we use today is dates. We use them in file names, reports, database fields, etc. There are many ways to enter a date:

• 2024-12-20
• 20 Dec 24
• 12/20/2024
• 20/12/2024
• Dec 20, 2024
• etc.

RFC 3339 (YYYY-MM-DDTHH:MM:SS+HH:MM) is increasingly becoming an international standard. Many programming languages (Go, Rust, Javascript, Elm) support RFC 3339.

What about when naming files? It is often helpful to put a date in directory or file names so you can easily sort to find the latest or construct a timeline of events. In this case it makes sense to format the date general to specific YYYY-MM-DD and put the date at the beginning of the filename:

• 2024-10-20_project-requirements.docx
• 2023-11-01_architecture-rev1.pdf
• 2024-11-11_architecture-rev2.pdf
• 2024-12-15_release-v1/

With a little thought, even simple things like file and directory names can become useful metadata that is easy to sort and query. Consistency and standards – simple things you can do to make things better.

[khem]

this is small tweak results in big benefits

[bmoyers]

Nate introduced me to this about ~10ish years ago and I’ve stuck with it ever since. It’s been incredibly useful for managing tons of design files with multiple revisions.

[cbrake]

The biggest benefit to frequent updates

Perhaps the biggest benefit of frequent updates is that the changes are small, making them easier for humans to absorb and adapt to.

The conventional wisdom in our industry is that frequent updates mean things are always breaking. This has not been my experience; rather, things are continuously improving in small ways, and the changes are much easier to adapt to.

Arch Linux is a classic example – always improving, rarely breaks, and when it does, you can usually find a fix in a few minutes. Zephyr is another example – always improving, and rarely problems merging in the new changes.

When things break or change unexpectedly, you are only dealing with one issue at a time, not dozens or even hundreds.

This is more organic and enjoyable – the way natural systems work. Small continuous changes (either good or bad) are better than large step changes and much easier on the system.

[cbrake]

Humility

An essential mindset for platform thinking is humility – the realization that we as humans are finite, we make mistakes, we don’t always perform at the same level, we get lazy and tend to take shortcuts.

YOUR Platform can compensate for much of this as it does the boring tedious work, checks for mistakes, deploys reliably, provides structure, etc.

But we need to acknowledge this first, and that is the first step.

[cbrake]

Platform reflection

How has YOUR Platform done this year?

Have you burned down technical debt?

Have you automated repetitious or tedious tasks?

Is your test coverage increasing or decreasing?

Are you releasing more often?

Are deployments getting easier?

Are you deploying with more confidence?

Is your documentation getting better?

Is it easier for new people to get up to speed?

Do you have any new checklists?

Have any existing checklists been automated?

[khem]

good checklist one can verify with !

[cbrake]

Joy

Platforms help bring the joy back into engineering.

How? – by assisting you with the tedious error-prone tasks, and freeing you to focus on the valuable creative work.

Satisfaction comes from being useful and creating value. We need to get to the place where we can do that work.

[cbrake]

Preparation - lessons from the kitchen

Most Sunday mornings, I make gluten-free waffles for breakfast (see recipe at the end of this post). I like to get everything out (ingredients and utensils) before I start.

This seems to make the process go faster and smoother. There is an efficiency in focusing on getting everything first, and then cooking.

So I was wondering if there is an analogy to product development. What are the ingredients for product development?

1. clear definition of the goal and next steps
2. any relevant documentation
3. tools (editor, CAD tool, issue tracking systems, build systems, tests, release processes, etc.)
4. collaboration with others on the team (issues, PRs, discussions, etc.)

Is this scattered all over the place, or can you quickly assemble all of this and hit the ground running?

It helps to organize your work in a notes system. This has links to relevant information and notes so you immediately have all the relevant context.

For some tasks like code review, tools can prepare the task for us. Github/Gitea/Gitlab pull request (PR) workflows have the code, discussion, and proposed changes all in one place.

With any task, having all the ingredients at hand makes for a nice result! Preparation leads to focus.

Gluten-free waffle recipe:

[cbrake]

The problem with experts

At a recent family holiday gathering, we happened to be discussing how crazy family life gets at times – you are halfway through cooking something and realize you don’t have the ingredients on hand, so you need to improvise. Some of the men in the group described how they always get everything out first before starting, which ironically I also do. Some of the females commented this was unnecessary as they had done it thousands of times, so it was easier to get stuff as needed. They have a pretty good sense of where stuff is and what they have on hand – 99.9% of the time it works pretty well.

Perhaps this is a general difference between men and women – women are generally better at multitasking. But I think there is also another factor at play – with food preparation, the women in our families are experts, and the men are amateurs. Experts are very good at what they do. They don’t need a process to prop them up. However, in the cooking example it is more difficult to scale these methods to their husbands or children.

The real value in expertise is in scaling it. Do we document what we do? Can we make it easy for others to follow? Can we make it easy to find the things we need? Can we create processes that reduce errors and blockers?

In the kitchen, these differences between the amateurs and experts are mostly amusing and not all that critical, but in business and product development it is. Experts need to be creating and contributing to platforms. This is the difference between a sustainable business and a few talented individuals. Unfortunately, many experts don’t personally feel they need a platform, so have little motivation to contribute to one.

When you hire, expertise is important, but so is Platform Thinking.