In MHO there are two types of criticism, constructive and its opposite, destructive and depending upon the circumstances one must select which to use.

In the case of poorly written code, if I have an idea as to how to improve the code, then the constructive technique is what I have used. Saying things like “have you tried and tested yyy ?”. If the persons answer is “no I have not” I then follow up with the suggestion, “Please do so and let us compare the results of each” If they have tested my suggestion, again I request a comparison of the results, and in some cases I have learned something and I will compliment them for that.

As a team lead or supervisor I have always insisted on proper documentation, starting with the objectives, and equally important IMHO is what the code SHOULD NOT DO. Failure to have the required documentation as a first time mistake, my criticism is constructive. If it is a habit of an individual not to produce any documentation the criticism is by anyone’s opinion definitely destructive, for the individual is violating a standard requirement, and testing my authority as his/her supervisor.

In the few instances where I have been an outside consultant, I treat the lack of documentation following a constructive pattern, by explaining to those who employed me how proper documentation would have reduced the time I have spent correcting deficiencies and hence their cost. Seems like everyone from the lowest denomination, to the highest supervisor understands the almighty dollar and the need to reduce unnecessary expenditures.

So like all things involving any coding/database projects the “It depends” mantra is always present.