>>>I do it all the time, If you deliver poorly written code that is difficult to maintain, you're doing your customer a disservice and providing shoddy work. As a professional, I would expect to be paid to the job and for doing it right. The nature of software development is that you don't always get it right the first time. Sometimes I do get it right, sometimes not, because it takes time to fully understand the problem and the solution. Sometimes you don't fully understand it until you've gone the wrong path. My customer pays for me to learn about how to fix the problem and for the fix itself.
>>>
>>>>"When you get the code working, rewrite it so it looks like you knew what you were doing all along"
>>>>
>>>> then try billing the client for that.
>>
>>Yes but quite often a client will want function now and rewriting something that works adds zero functionality now. All this rewrite for correctness strikes me as ivory tower stuff.
>>
>>If you write crap at least comments help.
>
>There's a school of thought that says "Comments are lies". When I first heard about it I thought it was total nonsense. Now I think there's a lot of truth to it. If you add comments, you have to maintain them just like you maintain the code itself. Far too often, even with my own code, I've run into cases where the code's been updated but the comments haven't - so the comments are lies, or at least misleading or incomplete.
>
>If code is "crap" then the comments are almost always worse.
>
>Every experienced programmer knows that the absolute best code is no code at all. One could similarly argue that the best comments are no comments at all. The holy grail is code written such that its purpose and operation is obvious to anyone with a reasonable grasp of the language used, and with no comments required.

I would agree that most code should be self documenting when read by a good programmer, but I always like to add comments (and maintain them up to date) when something is not obvious. That includes changes by management that you know will create problems. Who made the change, and why! Some members of management like to control everything and do not listen to reality.

Maintain your code and comments. One user (a super project I had) who was in charge of a project would change her mind about every three months. I would block out the old code, add comments why, write the new code with comments and date everything. After a few years of this you would not be surprised that the user actually required the old functionality or a previous version. This happened so many times with the same application (a web app with 309 forms) that it became a daily occurrence for some of the forms.

When I was consulting I would have a written agreement with the customer. After delivering the final product and showing the customer how to use the application, often the user would have a light bulb go off in his or her head. “Gee, could the program also do….”? I would answer, “Yes, for $120 an hour”! :)