>There's still the "if it's not broke, don't fix it" factor. The client has a working program, and there's no justification to change the code and billing them for the work if there's no functional change. And they like the current functionality. You probably run into that a lot, where there a section of code that you know can be built better, but since the current code work, you cannot justify the change to the client.

Unless you believe in 'Refactoring' and feel that it will make continued maintenance easier and faster.... judgement call.