A client recently asked me to write down some suggestions of best practices and process improvements for his company. I noted several suggestions, sorted them into four categories, and started writing them up. Partway through this process, I noticed that two of my recommendations seemed to contradict each other. On one hand, I said not to force the whole company to use the same software toolset. On the other hand, I also said that everybody on the same project should use the same software toolset. So, what was I advocating? Should everybody use the same toolset or not?

As I pondered this apparent contradiction, I stepped back to consider the value of all my suggestions, when an abstract thought came to my engineering brain: “Intangible Benefits.” Engineers love to measure things and assign a number. But how do you measure something intangible? You can’t, but there are times when you must take it into consideration.

For example, buying software X over software Y because X is cheaper than Y is based on a tangible benefit of measurable cost savings. However, if engineers using software X take 50% longer to do their job than engineers using software Y, that’s bad. There is an intangible benefit to buying software Y in terms of engineering productivity. Measuring productivity is imprecise and takes a long time. Was it really 50% better? Maybe it was 25% better or 75% better. Unfortunately, companies typically do not have the luxury of buying and installing both X and Y, then letting the engineers work for a year while collecting data so that tangible results can be measured. Instead, we make our best guess. Software X may be cheaper, but software Y might make a team of several engineers more productive, an intangible benefit.

In the hardware/firmware realm, here are three best practices that have intangible benefits.

• Best Practice: Firmware engineers should read the chip’s external specification during the chip’s design phase and provide feedback in a timely manner on the chip’s design, functionality, and documentation.

This practice can help catch hardware problems early on, when they are still easily correctable, providing the intangible benefit of saving time, cost, and headaches in the future.

• Best Practice: Provide an abort for each task in the block.

I have seen a few cases where not following this second practice required extensive engineering effort down the line to work around this lack of functionality. When such a problem occurs, we can measure how much effort we had to spend to work around it. But, how do we measure the intangible benefit of effort not spent to solve a problem that did not occur because we followed good engineering practices?

• Best Practice: Add a register showing the level of key signals internal to the block.

What is the intangible benefit of adding nine debug hooks that are never used? Probably not much. But what is the benefit of adding a tenth debug hook used to solve a difficult problem? I have used several debug hooks over the years. Some helped to quickly diagnose a problem, saving a few days of effort. Others were used to working around defects that, had the hook not been in the chip, would have required a chip respin costing at least a three-month delay and $500,000.

Finally, back to my question in the opening paragraph: Should everybody be forced to use the same toolset or not? The answer is “yes” for those on the same team, but “no” for the whole company. All car mechanics on the BMW team should have the BMW special tools, but the BMW special tools will not help those on the Honda team.

Until the next intangibly beneficial newsletter…