A few months back I got involved in a small conflict between two vendor and customer teams. I had a long history of working with both teams, and I started from the point of view that neither team was likely to be completely wrong. They are both great teams with many smart, hardworking members. As I listened to details from one team, and then later heard from the other team, my suspicion was confirmed.
Each team had made some mistakes (for example: bad assumptions or poor choices in communications) and the hard feelings generated by the process had festered to the point of damaging the relationship. Like many arguments, once feelings are hurt, even if you fix the immediate problem, the anger can take far longer to cool down.
During our discussions, one engineering leader made the comment, “Problems always occur at the Interfaces.” This struck me as a brilliant truth in both human and technical terms.
Yes, the misunderstandings between people will be worse at the interface between two groups working at separate locations. Increasing distance almost always leads to larger misunderstandings. Two teams working at great distance will communicate less frequently than two teams working side-by-side. Any difference in language, culture, or time-zone will greatly increase the friction between the two teams.
Increasing distance also increases the delay time for corrections. Let’s say for example, that while standing in front of you, I asked you to manufacture a small metal part; and you replied with the inquiry, “Aluminum or Steel?” No problem, I could communicate my requirement instantly.
But if I sent you this request by email, you might assume that I must have meant aluminum. This is especially true if working together, we had recently developed several other aluminum parts. Later, when you ship me the part, there might be weeks of delay before I realize and explain the misunderstanding (for example, why the part needed to be made from steel). Project time, effort, and resources have been wasted.
Maybe you conclude that I am too picky. Maybe I assume you are careless, even if you had excellent and logical reasons for the choice you made. We both would be wrong in those assumptions. I had a reason to want steel, but failed to communicate that key requirement. You had logical reasons to build that new part with aluminum, but failed to confirm my required material.
I have seen many electrical designs crash on the rocks of poorly specified or poorly understood interfaces.
A vendor once insisted that their chip could communicate to other chips using a common interface bus—but they had built in NEGATIVE timing margin. In other words, the data disappeared from the bus before the clock edge intended to latch that data. Redesigning the external circuit required the addition of an external latch, requiring a new spin of the printed circuit boards. Project time, development costs, and final product cost all increased.
Many years ago, I encountered two chips that had been developed by the same group at a silicon vendor. The first chip specified a VOH of 2.4V and the second chip specified a VIH of 2.6V. The two chips were meant to connect directly, but could not guarantee that a HIGH output from the first chip would be recognized as a HIGH input at the second chip. Fortunately, the silicon processes turned out to be far better than the datasheet writers, so this problem was solved by rewriting the product specification.
Occasionally, inexperienced engineers will specify a power supply based on the typical power loads of a given circuit. That circuit works fine--until it doesn’t work; and when it doesn’t work, it might be too late to easily fix. If the design is in a life-critical system, well, the results are not pretty.
Software can suffer equally critical problems at the interfaces. Much malware is based on simply passing more data than a given software function expects. Does your code validate the input? Or does it open the door wide to the conquering invaders?
When you are practicing teamwork and doing technical design or verification, problems will always occur at the interfaces. Try to build some reasonable verification into your human processes and also your technical checklists. And please: do everything possible to reduce friction and improve communication at the interfaces.