Eric Bogatin, Signal Integrity Journal Technical Editor
Eric Bogatin, Signal Integrity Journal Technical Editor RSS FeedRSS

Eric Bogatin_new headshot_100

Eric Bogatin is Technical Editor at Signal Integrity Journal and the Dean of the Teledyne LeCroy Signal Integrity Academy. Additionally, he is an Adjunct Professor at the University of Colorado - Boulder in the ECEE Dept. Eric improves the signal to noise ratio by sorting through all of the information available and finding the best quality content to publish on

Signal Integrity / Power Integrity

Bogatin’s 20 Rules for Engineers

January 14, 2020

I love lists, and I love rules. What could be better than a list of rules? If you are a fan of NCIS, you will be familiar with Gibb’s rules.

Over the years, I have presented to and worked with thousands of engineers, from very young to very old. Many of the problems they bring to me have a small set of common answers. I’ve collected these into 20 basic rules of engineering. This particular list of rules is not about specific design rules but about process rules. (And not all of them are actually rules. Some are more observations to be aware of when you are tackling a problem.)

Here, collected in one place are my latest Rules for All Engineers:

1.The most common answer to all signal integrity question is “it depends.” The way to answer “it depends” questions is by putting in the numbers with rules of thumb, approximations, and numerical simulation tools.

2.The way to separate myth from reality is by “putting in the numbers” with rules of thumb, approximations and numerical simulation tools. (can you tell this process is an incredibly valuable skill?)

3.Watch out for the “whack-a-mole” effect. (I learned this from Scott McMorrow.) When you make a change in one design feature to improve performance, it usually affects another performance property of the system. Decrease a line width for higher interconnect density, a good thing, and the trace resistance increases, sometimes a bad thing. Pay attention to the impact one change will make in all aspects of the cost/performance of the product. Whenever possible, balance the system level cost/performance tradeoffs. This is also called the law of unintended consequences.

4.The most important step in fixing a problem is finding the root cause. If you have the wrong root cause, you will only fix the problem by luck and then mess up your ability to solve future related problems. Take the extra time to confirm you have the correct root cause. It will save you time, effort, and false starts in the future.

5.Apply the Youngman Principle to turn a root cause into a design guideline. This is based on a story by Henny Youngman. The punch line is, “If your arm hurts when you raise it, don’t raise your arm.” If you know the cause of a problem is because of a design feature, then eliminate this design feature in your product to eliminate the problem.

6.Sometimes an okay answer NOW! is more important than a good answer late. There are occasions when an estimate that you can do quickly can indicate how close to a problem you may be. If you are far from a problem area, move on to a more important problem. If the estimate says you are close, then it can justify spending the extra time and expense to get a better answer.

  • You may never have all the information you need to make a good decision. Use what you know, use your judgment, and consider a later, follow-on investigation to get the additional important information for a better decision.

7.There are some design guidelines that will fix known potential problems. These are called Best Design Practices. When following a best design practice does not cost any extra and is free, it should always be followed. These should become habits. Like, always use a continuous return path adjacent to every signal path. Unless you have a strong compelling reason, always follow these habits.

8.Evaluate the “bang for the buck” with virtual prototypes. Following some design guidelines may not be free. To evaluate whether a design change or new component is worth it, use a “virtual prototype”- a calculation- to see if the performance gain is worth the potential extra cost. A calculation: a rule of thumb, an analytical approximation, or a numerical simulation, will tell you to the accuracy level you need, the potential performance gain.

9.Never perform a measurement or simulation without first anticipating the results you expect to see. Never believe a measurement or simulation blindly. If it doesn’t match what you expect, there is a reason for it. Either there is something wrong in the setup of the tool, or maybe your intuition is off, in which case this is an opportunity to re-calibrate your engineering intuition. Do not proceed with the result unless you can convince yourself it is reasonable. (Rule #9 is so popular, it now appears on hats)


10.Corollary to Rule #9: It is easy to perform a measurement or simulation. It is hard to eliminate errors and artifacts. It is just as easy to screw up a measurement as it is to screw up a simulation. While you can never prove you are correct, you can demonstrate the result is consistent with other analyses or measurements. You can never perform enough consistency tests. If you think you know why a result looks the way it does then ask: what else might be the case? Look for it to confirm you know what is going on and the measurement or simulation is consistent with the way you think it should operate.

11.To get it right the first time, start with what you believe to be best design practices applied to your application, and build virtual prototypes at every step along the way to balance the cost/performance tradeoffs.

  • Use measurements to quickly debug problems and get it right the second time. (This later process comes from Dave Graef)

12.Watch out for mink holes. A rat hole is a convoluted path that you enter and it takes you farther and farther away from your goal. A rat hole is a distraction from your main goal. A mink hole is a rat hole lined in mink fur. It is a convoluted path that takes you farther and farther away from your goal, but it feels really good while you are in it. Identify early what might be a mink hole and don’t get caught in it for too long.

13.Hope can’t be part of the design process. One way to have confidence in your design before you release it is to build a virtual prototype using rules of thumb, approximations, and numerical simulation tools.

  • Simulation is like flossing. It is highly recommended but not everyone does it. If you don’t simulate your design, it does not mean it will not work, it just means you have higher risk your design may not work.

14.Just because it is possible to do something technically does not mean it makes good business sense to do it.

15.Every design is a tradeoff between achieving a target value of your product and its cost. The value is in the form of the performance- what its features are and how well they meet this targeted specification. The cost is in the form of the $$$ for the product, the time schedule, and the risk. Usually, implementing a performance feature will cost $$$, schedule, or risk. And, achieving a reduction in one cost element will usually increase one or both of the other two. Designing for lower cost may increase risk. Reducing risk may increase the schedule.

16.Everything we do in engineering is about creating something that has value at an acceptable cost. This is why Bruce Archambault says “engineering” is Geek for “tradeoff analysis.”

17.An expert is someone who has already made all possible mistakes.

18.To reduce the risk of a problem arising in your product, design more like a mom and less like a dad. A mom will think of all the worst-case scenarios, “You could put your eye out with that thing.” A dad will be willing to take more risks. Before trying something risky, a dad will say, “here, hold my beer.” Think of all the possible problems that can arise in your product and develop a risk reduction strategy.

19.There are two kinds of engineers, those who have signal integrity problems and those who will.

20.There are two kinds of engineers: those who are building antennas on purpose, and those who are building them, but not on purpose.


You must login or register in order to post a comment.