How do you get a customer to accept better practices and cross-platform debugging during development?

Question

Our customer has a "No unnecessary code" policy. And the people they have assigned to my project thinks this includes:

• Dianostic code
• Cross platform compatibility code
• "Software" faultcodes. ("Software doesn't break therefore these are unneeded.")
• Class methods that aren't used for THIS application ("Customer Code Review Issue : Please verify all methods are actually called and remove unused code." Say hello to a divirgent code base.)
• Anything that THEY believe the end user won't care about. (They never actually ask the end user.)

They told me I can have a version I use for "verifying algorithms" but it has to be removed from the customer submittles. I try and explain I can't verify to a different build than I'm submitting, but they don't seem to get it. The cross platform stuff is significant because we typically start both hardware and software designs at the same time, early development has to use a different set of hardware for testing/debugging.

Answer 1

It's not clear who owns your code (your employer or the customer) or whether your customer is unwilling to pay for this code or simply unwilling to ship with it. If your customer thinks they don't care about cross-platform, for example, they're quite right in being unwilling to pay for something that may benefit them only in the future, or may benefit only your other customers.

Also, if your customer is developing for an embedded platform, every byte of ROM and RAM counts, and again they're right in asking you to eliminate unnecessary code.

So how do you maintain a single, unified, non-divergent code base while still satisfying the needs of this customer? Specialize!

I have a colleague who founded a company whose sole business is the USB software stack. They have unbelievable cross-platform issues, configuration, and so on. Their solution to this problem is to have a single code base, and then they automatically specialize it for each customer. The automatic specialization includes things like removing code deemed "unnecessary" on a particular platform. Without knowing more about your problem, your business, or your other customers, that's the path I would recommend for you.

Answer 2

Carefully explain that support requests will take exponentially longer without the diagnostic code in place, and that you cannot be held responsible for extraordinarily long turnaround times on support requests AND you expect to be paid dynamically based on the length of time required to fix a given issue, should the customer maintain their current software policy.

If they still hold to their views, go along with the customer. Until they're burned at least once, they won't feel the need to change their ways.

Edit: I assume unit tests and the like aren't included in your final deliverables, as that would be silly. Perhaps the customer believes this to be the case.

Answer 3

Write a simple script that generates source files to be reviewed from your actual source code.

Answer 4

This is a tough call. Most of the suggestions I'd have had have already been done, and commented on. But I do have one remaining one.

In a comment, you mention that "they typically forget our design objections when a real problem occurs and blame it on us anyway." That says to me that you're in something of a no-win situation.

Without knowing your relationship to this client, aside from its duration (and apparent combativeness), the only advice I have is to have written, validated documentation of design objections. It's a lot more work, but something of a CYA for when they overrule you, then blame you for the issue anyway. This may be less important if they already pay you for the T&M to fix issues discovered in the field, but if they expect you to fix those for free, this can be used as a negotiating chip.

A few rounds of making fixes hurt for them as much as they do for you, and they might just turn around and start allowing some of the diagnostics (if nothing else).