The customer is king. So as contractor you shall meet whatever the client has defined as quality standard. Or you risk to be out.

This being said, it matters very much how the (here poor) quality standards are defined:

• Contractual quality standards: the delivered code must comply, or otherwise it's a breach of contract. No choice.

• Formal corporate quality standards: even if it works perfectly, the code that does not comply will be considered bad quality by so many people, that you'll be old before you have converted them all to a better practice. Worse: well known tools can be used to automate and legitimate such quality metrics (e.g. sonar cube). Almost no choice.

• Ad-hoc criteria defined by a couple of persons at the client's. Here you could engage discussion. There is hope :-)

In this last case, there could be some flexibility, and you could try to diplomatically make the point. Here some arguments that speak against the customer's criteria:

• Productivity issue: the coding is done twice (once in English and once in code).
• Accuracy issue: if changes are done in the code, they must be done in the comments, or the comments might become useless.
• Refactoring issue: as refactoring tool doesn't process the variable names in comments.
• Risk issue: ambiguity (or obsolescence) of comments could generate confusion and risk to increase bugs.
• Quantity is not quality
• This funny collection of useless comments on StackOverflow.
• This article that argues that a high comment ratio could even be the sign of a code smell.

But instead of speaking against the bad and confront the customer, may be could you simply promote better approaches:

• Clean code (suggest the book to your customer: there's a convincing section dedicated to comments and self-documenting code).
• Documentation practice: The most difficult things to grasp, and hence the most valuable information, such as for example the relation and interaction between classes is better documented in a separate document (for example in an UML picture rather than 1000 comment words ?)

If the customer is still not convinced, you could propose an experimental alternative, using tools generate automatically documentation with comments, such as javadoc or doxygen. Propose therewith to shift the focus from quantity (25% of code) to quality (generate an understandable javadoc).

The customer is king. So as contractor you shall meet whatever the client has defined as quality standard. Or you risk to be out.

This being said, it matters very much how the (here poor) quality standards are defined:

• Contractual quality standards: the delivered code must comply, or otherwise it's a breach of contract. No choice.

• Formal corporate quality standards: even if it works perfectly, the code that does not comply will be considered bad quality by so many people, that you'll be old before you have converted them all to a better practice. Worse: well known tools can be used to automate and legitimate such quality metrics (e.g. sonar cube). Almost no choice.

• Ad-hoc criteria defined by a couple of persons at the client's. Here you could engage discussion. There is hope :-)

In this last case, there could be some flexibility, and you could try to diplomatically make the point. Here some arguments that speak against the customer's criteria:

• Productivity issue: the coding is done twice (once in English and once in code).
• Accuracy issue: if changes are done in the code, they must be done in the comments, or the comments might become useless.
• Refactoring issue: as refactoring tool doesn't process the variable names in comments.
• Risk issue: ambiguity (or obsolescence) of comments could generate confusion and risk to increase bugs.
• Quantity is not quality
• This funny collection of useless comments on StackOverflow.
• This article that argues that a high comment ratio could even be the sign of a code smell.

But instead of speaking against the bad and confront the customer, may be could you simply promote better approaches:

• Clean code (suggest the book to your customer: there's a convincing section dedicated to comments and self-documenting code).
• Documentation practice: The most difficult things to grasp, and hence the most valuable information, such as for example the relation and interaction between classes is better documented in a separate document (for example in an UML picture rather than 1000 comment words ?)

If the customer is still not convinced, you could propose an experimental alternative, using tools generate automatically documentation with comments, such as javadoc or doxygen. Propose therewith to shift the focus from quantity (25% of code) to quality (generate an understandable javadoc).

The customer is king. So as contractor you shall meet whatever the client has defined as quality standard. Or you risk to be out.

This being said, it matters very much how the (here poor) quality standards are defined:

• Contractual quality standards: the delivered code must comply, or otherwise it's a breach of contract. No choice.

• Formal corporate quality standards: code that does not comply will be considered bad quality by so many people (even if it works), that you'll be old before you have converted them all to a better practice. Allmost no choice.

• Ad-hoc criteria defined by a couple of persons at the client's. Here you could engage discussion. There is hope.

In the last situation, here some arguments that speak against the customer's criteria:

• Productivity issue: the coding is done twice (once in English and once in code).
• Accuracy issue: if changes are done in the code, they must be done in the comments, or the comments might become useless.
• Refactoring issue: as refactoring tool doesn't process the variable names in comments.
• Risk issue: ambiguity (or obsolescence) of comments could generate confusion and risk to increase bugs.
• Quantity is not quality

But instead of speaking against the bad and confront the customer, may be could you simply promote better approaches:

• Clean code (suggest the book to your customer: there's a convincing section dedicated to comments and self-documenting code).
• Documentation practice: The most difficult things to grasp, and hence the most valuable information, such as for example the relation and interaction between classes is better documented in a separate document (for example in an UML picture rather than 1000 comment words ?)

If the customer is still not convinced, you could propose an experimental alternative, using tools generate automatically documentation with comments, such as javadoc or doxygen. Propose therewith to shift the focus from quantity (25% of code) to quality (generate an understandable javadoc).

The customer is king. So as contractor you shall meet whatever the client has defined as quality standard. Or you risk to be out.

This being said, it matters very much how the (here poor) quality standards are defined:

• Contractual quality standards: the delivered code must comply, or otherwise it's a breach of contract. No choice.

• Formal corporate quality standards: even if it works perfectly, the code that does not comply will be considered bad quality by so many people, that you'll be old before you have converted them all to a better practice. Worse: well known tools can be used to automate and legitimate such quality metrics (e.g. sonar cube). Almost no choice.

• Ad-hoc criteria defined by a couple of persons at the client's. Here you could engage discussion. There is hope :-)

In this last case, there could be some flexibility, and you could try to diplomatically make the point. Here some arguments that speak against the customer's criteria:

• Productivity issue: the coding is done twice (once in English and once in code).
• Accuracy issue: if changes are done in the code, they must be done in the comments, or the comments might become useless.
• Refactoring issue: as refactoring tool doesn't process the variable names in comments.
• Risk issue: ambiguity (or obsolescence) of comments could generate confusion and risk to increase bugs.
• Quantity is not quality
• This funny collection of useless comments on StackOverflow.
• This article that argues that a high comment ratio could even be the sign of a code smell.

But instead of speaking against the bad and confront the customer, may be could you simply promote better approaches:

• Clean code (suggest the book to your customer: there's a convincing section dedicated to comments and self-documenting code).
• Documentation practice: The most difficult things to grasp, and hence the most valuable information, such as for example the relation and interaction between classes is better documented in a separate document (for example in an UML picture rather than 1000 comment words ?)

If the customer is still not convinced, you could propose an experimental alternative, using tools generate automatically documentation with comments, such as javadoc or doxygen. Propose therewith to shift the focus from quantity (25% of code) to quality (generate an understandable javadoc).