In the dynamic world of engineering, engineering rules serve as guiding stars, steering professionals of all disciplines – be it software, mechanical, or others – towards success. These rules are the compass that helps us navigate away from costly mistakes, safeguard users, and strike a delicate balance between risk and reward. Throughout my career, I’ve had the privilege of encountering a diverse array of engineering rules – some proving invaluable, while others falling short. Today, I invite you on a journey to unlock the first five engineering rules that I believe hold the power to pave the way for unparalleled success. Embracing these principles will elevate your endeavors, enabling you to achieve greatness time and time again. So, let’s embark on this exploration of indispensable engineering rules!

Rule #1 – If it doesn’t fit, don’t force it

The first rule I ever learned about engineering was taught to me when I was fourteen years old as a student on a FIRST Robotics team. One of our General Motors engineer mentors explained to a group of 10 students how to assemble pieces for an electronic cart we were building. As part of the run down, he nonchalantly mentioned that the first rule of engineering is that if it doesn’t fit, don’t force it; wise words still reverberate with me more than 25 years later.

It doesn’t matter what type of engineer you are; if it doesn’t fit, don’t force it! But unfortunately, even in embedded software, there are times when libraries or modules just don’t seem to work together well. When this happens, it’s a sign that we should stop what we are doing and reevaluate the right path forward. Only after careful consideration can we then proceed.

Rule #2 – Sometimes, you must force it

Shortly after the students broke up to begin assembling parts, I was assigned to work directly with our mentor to assemble a few components for a different part of the project. As we were working, two parts just wouldn’t quite go together. The machined tolerances might have been too tight to slide together perfectly.

I was a bit excited! Here was engineering rule number one playing out before my eyes! If it doesn’t fit, don’t force it! As I looked at my mentor in anticipation to see how he would resolve the issue, he did something peculiar. My mentor looked around the room cautiously, looked me directly in the eyes, and said, “Engineering Rule #2, sometimes you must force it”. With that, a hammer came down on the parts in a single, fluid movement and seated them together perfectly.

The second rule of engineering teaches us that we are responsible for managing risk as engineers. It is good to be conservative with rule number one, but when the engineer weighs the risk versus the cost, delivery time, and so forth, sometimes you must force it and work with what you’ve got. Engineering decisions aren’t all night and day; each decision is about managing risks.

Rule #3 – You can generalize, but there are always exceptions

The first two engineering rules have taught me through observation and experience the third rule of engineering. You can generalize, but there are always exceptions. As engineers, we love to create best practices, standards, and guidelines that manage the risks for us. For example, if I want to minimize the potential for bugs in my C code, I might adopt the MIRSA-C standard. On the other hand, if I want my colleagues to be able to read my code seamlessly, I might adopt or write a C-style guide. Between the two, I’m trying to manage the risk to the software quality, cost, and delivery deadlines.

The problem with standards, best practices, and guidelines is that they are often generalizations. They tell you to do certain things or not do others. However, the potential problem is always exceptions to the rules. For example, many C developers are likely familiar with the MISRA-C standard. MISRA-C provides guidelines that can help improve software quality and minimize defects. However, there are times when one might want to deviate from the standards suggestions to solve a coding problem. Thankfully, even as part of that standard, they allow exceptions to the rules. They know that they can’t possibly imagine every use case that an engineer might encounter. However, they do make developers justify their deviations.

Rule #4 – Live by the 80/20 rule

The 80/20 rule, often known as the Pareto Principle, states that 80% of outcomes result from 20% of all causes. Pareto’s Principle, if applied to engineering, can transform your ability to deliver on time and within budget. For example, using Pareto’s Principle in engineering might look something like this:

            80% of product features can be delivered in 20% of the time.

            80% of product features can be delivered in 20% of the budget.

At first, this might seem absurd; However, think back to the last few projects you worked on. At the start of the project, new features were probably added quickly, and right around the 80% mark, the project started to go sideways.

I often look to the 80/20 rule to state that it’s good enough to ship when something is 80% ready. If the product has 80% of the features, the product is ready to ship if those are the most used features. When I write, I recognize that I could spend five times as much time rewording sentences, adjusting sentence structures, and so forth. The additional time in most cases, doesn’t make the points clearer and isn’t even noticed by the reader. (Except for the occasional spelling mistake).

Apply the 80/20 rule to every aspect of engineering, and in many cases, you’ll discover it’s “good enough”.

Rule #5 – Always Manage Expectations

Successfully delivering an engineering project does not result from writing the best software, the most elegant mechanical design, or even delivering within the budget and time constraints. An engineer or team can do all those things and still be perceived to fail. The key to success in engineering isn’t always technical; it’s often about managing the human element. Success comes down to how well you can manage expectations.

Expectations management is an issue throughout the embedded systems industry. Time and time again, developers over-promise and under-deliver. Nearly half of all embedded systems projects are delivered late and over budget. In other words, roughly half of all embedded systems projects are viewed as failures. This is because the expectations for these projects were not correctly set; otherwise, 100% of projects would be delivered on time and within budget!

Managing expectations can easily be seen in Scotty from Star Trek. The fictitious chief engineer is often asked to do the impossible by his demanding captain. (Sound familiar?). However, Scotty never caves to management’s demands; he always pushes back to set realistic expectations. He often pushes back so far that when he does deliver, he’s viewed as a miracle worker! I’m not suggesting we push to the extreme like Scotty, but every engineer should adequately manage expectations. The result will be happier customers, bosses, and maybe even a more relaxed engineer.  

Engineering Rules Conclusions

Engineering rules are generalizations that can help guide and improve product quality, delivery budgets, and schedules. Every engineer will have rules they discover through their career that allows them to deliver their engineering solutions. The five rules we’ve looked at in this post are general rules that I have found helpful and, to some degree, even humorous. The critical point is that rules help us to define the best practices and standards that elevate the quality of our work and help us provide more value in shorter periods.

An Engineering Rules Question . . .

What engineering rules have you encountered in your career, and what impact have they had?