I am by nature an optimist, but this does not match my experience, particularly with regards to improvements that the client cannot easily perceive. (Some days I wish apps had an XP bar so I could award a few points for e.g. "Won't die if the school gets about two dozen Chinese students who prefer English to Japanese - actual bug, by the way.)
Well, there's a trick to it. You have to let them know you are fixing things. It's even better if they know everything that's broken and can prioritize what they want fixed first.
I went through a lot of pain before I realized I needed to toot my own horn more. After that, suddenly they were very grateful that I was fixing bugs in their application. (To be fair, they were very grateful at first, too, when the bugs were really obvious and costing them money daily.)
There's no harm in letting them know exactly how much you've improved their system. They really will appreciate it.
Maybe I should have distinguished between maintenance programming as a member of a big IT department, or maintaining your own code, versus fixing and enhancing code the original programmer has abandoned or moved on from. I do maintenance programming freelance so whatever bad feelings or history my client has it doesn't rub off on me.
I am by nature an optimist, but this does not match my experience, particularly with regards to improvements that the client cannot easily perceive. (Some days I wish apps had an XP bar so I could award a few points for e.g. "Won't die if the school gets about two dozen Chinese students who prefer English to Japanese - actual bug, by the way.)