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

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.

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.

They are including "#if INTEL dothis #elseif TARGET dothis #endif" code which doesn't effect the final build image. And yes they own the code, but we are responsible for long term maintainance. So removing dianostic capability leaves us blind in the field and still responsible for "Why the hell doesn't this damn thing work?" issues with no eyes on the problem.

– NoMoreZealots Aug 16 '09 at 21:37.

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).

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.

I know the "If they still hold to their view, go along with the customer. " part falls along the "customer is always right. " But my fear is giving a negative impression of the technology to thier client.

And besides, they typically forget our design objections when a real problem occurs and blame it on us anyway. – NoMoreZealots Aug 16 '09 at 22:16.

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

I kinda like that idea, but I have to admit it's bit of smoke and mirrors. "I AM THE ALL POWER OZ, never mind the man behind the curtain. " But in the end they have to see what code was used to generate the .

Out file. I want the capability to go out in the field and say "OH, I know what's going on" and preferably change a configurable set of constants and fix it. – NoMoreZealots Aug 16 '09 at 23:13.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.