Find the Right People, Ask the Right Questions

Technical jargon can sometimes be overwhelming, especially when the customer is a foreign company whose employees speak English as a second language, if they speak it at all.  Sometimes, a seemingly insurmountable difference can be resolved by a quick sidebar conversation between the right people.

The System

SafeCode's consultant was engaged in the development of a complex aircraft navigation system at a major aerospace and defense OEM.  This was a high-profile project, as the system was to be featured in a widely publicized new aircraft.

The development group was large, and the codebase consisted of roughly a quarter-million lines of C and C++.  As a DAL A development effort, the development standards were very strict and comprehensive.  

The Challenge

For months, the aircraft manufacturer, the client’s customer, had been raising concerns about the C++ coding standard in use. The aircraft manufacturer was a non-U.S. company, and language had been a barrier that occasionally created tension, but it was generally resolved pretty quickly.  In this case, the client organization had tried repeatedly to understand the customer’s objection concerning the coding standard. Meetings had been held. Discussions had circled. The issue had become a formal audit finding with schedule implications.

The development team could not figure out what, specifically, the customer found objectionable. Each attempt to resolve it had produced more discussion without resolution. When the customer sent the audit team for an on-site visit, SafeCode's consultant, who had prior involvement in coding standards development, was invited to the formal audit meeting.

The Approach

The meeting was large and formal; tables arranged in a rectangle around a speaker's podium. The coding standard issue came up. Discussion went back and forth. Progress stalled. During the lunch break, rather than filing out with the rest of the group, the consultant walked across the room to the customer's QA representative and asked for a few minutes. When the representative agreed, the consultant asked him a direct question: exactly what risky code was it that he was concerned the current coding standard would permit?

The representative took out a sheet of paper and quickly sketched the "dreaded diamond" — a well-known multiple inheritance problem in C++, where ambiguous member resolution occurs when a class inherits from two classes sharing a common base. For well-understood safety reasons, virtual functions were already explicitly prohibited by the standard. But multiple inheritance itself had never been named. The consultant asked: if he added a single explicit rule prohibiting multiple inheritance, would that close the finding? The representative smiled and nodded.

The consultant was stepping slightly above his authority in making the offer — but he was certain it would be approved, and it was. He added the rule, notified all teams, and spent several days doing a regression review of the codebase to confirm what he already knew: multiple inheritance had not been used anywhere in the system.

The Outcome

A formal audit finding that had been open for months was resolved in a brief conversation during a lunch break. The fix was one sentence. The underlying problem had never been a technical disagreement — it was a vocabulary gap. The customer had a specific, well-defined concern that had never been articulated precisely enough for anyone to address it. Once it was, the conversation was over in minutes. 

Corollary Lesson

The consultant understood that the coding standard's prohibition on virtual functions already avoided all of the dangers generally associated with the "dreaded diamond".  The customer’s concern was completely unfounded.  On the other hand, the new rule was a simple fix that could be added with no code changes.  Reviewing all of the code was relatively easy, since only class declarations needed to be reviewed.  The simplicity and rapidity of the solution created goodwill with the customer and gave them confidence that their concerns would be addressed efficiently.  The customer may not always be right, but they are always the customer.