>>>>>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'm talking (typing actually) about comments that describe the business reason behind what you're doing which may not be obvious.
>
>So am I.


I think our starting points may differ. :-)