I think @aaronaught made some good points, which really leads to the answer I wanted to give, which is that it really depends on who's making the change (and why) and who wrote the code.
In my personal experience code is normally changed because either it doesn't work as intended, or you simply need to extend what it actually does.
In a Team dev environment, you shouldn't have to (and may not be able to) talk to the original coder, everything should be clear from the code.
That then leads to the question which consumes most of my time, which is what did the original programmer intend, and it is that question which most often leads to code being deleted, and is why we should comment everything, and where inexperienced junior programmers most often fall foul.
Any programmer that is changing someone else's code (refactoring) really should as a matter of courtesy and practice copy the same coding style of the code already in place, and first take steps to figure out how the original code worked, and what it was trying to, and actually going to, achieve. Often this in itself identifys bugs, but certainly it forces people to endure the pain that the next person will have looking at your code.
In my team anyone can delete, refactor or rewrite anything, and I view 'ownership' as a practice which breeds lazyness, as if one person is sure to be notified of any changes, why would they need to make the code readable.
So in short, no, you shouldn't have to ask the original author of the code, and if on looking at the code you do, then it is a sign that either his code isn't readable enough, or you need to improve your skills. However, I find it good form to leave the original code in place, commented out, until you're absolutely sure that in rewriting, you haven't accidentally removed required functionality. Nobody is perfect.