Have you ever been tasked to fix a bug or implement a new feature in a piece of code that had not recently been worked on? If so, what was your reaction when you studied the existing code? Were you able to easily integrate your fix/feature, or did you wince in agony and curse the previous developer? Assuming that you and your peers are usually adequately equipped to do a good job, how can it be that you made this experience? Why do all professional developers make this experience frequently? Surely, we don’t leave code in such bad a state, so why does it often appear to be so inadequate when we return to it? This raises the question: does software corrode? In this talk about refactoring, we discuss the titular question, as well as methods to deal with the “corrosion” effect. We address not only the general principles of refactoring, but also cover techniques for handling large refactorings in critical systems. Afterwards there will be something to eat.