Why I Start with the Grinder

I will be the first to admit it: I have been known to end up in the weeds from time to time.

You might be thinking: “Dave, you started with Project Inheritance. Roll up the sleeves, check the basics. We get it. But what does any of that have to do with MISRA, CERT-C, LINT, or those Ganssle standards you are ranting about?”

It is a fair question. It is an important question.

When we inherit a project, the shine of the new is a powerful distraction. We want to see the LEDs blink. We want to see the protocol churn. We want to build.

But we often forget the basics of figuring out where we are standing:

• Can I clone the branch to a virgin machine and build it?
• Are we so driven to justify our position that we jump in headstrong, hacking our way through just to get things working?

Testing the basics is not exciting, and it does not earn immediate accolades. But patience is a virtue, and patience now pays great dividends later.

The Soul in the Machine

I am a weekend warrior in the woodshop. One thing I have learned from true craftsmen is that they take as much pride in the parts you cannot see as the parts you can.

Embedded development is the same. It is about telling a story—the hows and whys of a solution. As crazy as it sounds, I am a firm believer that the story is the soul in this beautiful interface between code and metal that animates a board and creates new life.

That story is rarely seen, and I pride myself on taking great care of those parts that may never be seen. That care manifests itself in a solid foundation that can be built upon and improved for years to come.

A Quiet Build Log

You cannot continue building the house until the bed is made. A quiet build log is the best place to start.

Does a quiet log mean the source tree is 100% solid? Not necessarily. But it tells me a lot about the pride the previous developer took in their craft. That creates a bond of trust. For me, it shifts the focus to logic and SFR handling rather than hacking through a forest of warnings.

A build that screams like a wolf at the moon is no way to start moving forward.

Trust, but Verify

I would not take my rig up into the mountains without checking the tires, brakes, and seals. I certainly would not drop 50–100 KLOC on an AVR, PIC, Cortex-M7, or PolarFire without checking the foundation.

In my career, I have been called on for due diligence reviews during acquisitions. Often overlooked was the quality of the source code—yet that is exactly where the long-term money in development support and feature expansion lives.

One of the wisest policies I ever saw was from a mentor, Pat A. As part of our release policy, we would grab a peer, run to a clean machine, clone, build, check warnings, and verify the binaries. That practice has remained with me ever since.

The Insurance Policy

LINT and static analysis tell me if the frame is rusted. They let me quiet the noise to better assess what is really going on.

As an independent consultant, my reputation is everything. If I inherit your project and it fails because of a legacy integer overflow I did not catch, that is on me. Compliance reports are my insurance policy and my legacy.

The audit framework I am sharing leans on the foundational work of Jack Ganssle, updated for the current regulatory landscape.

Look for an upcoming article about the standards themselves, or contact me for a copy of my 10-point Mechanical Audit.

Originally published on LinkedIn as “Why I start with the “Grinder””.