This is something I learned the hard way - by many times making the same mistake.
Let's say you have a function AdjustBitrate that accepts one parameter representing new bitrate in kb/s (whatever that may mean). It's prototype is simple:
procedure TBaseClass.AdjustBitrate(newBitrate_kb_s: integer);
Due to a changed requirements, you have to redesign this function so that it will take not a new bitrate, but a bitrate increase (relative to the existing bitrate). What do you do?
procedure TBaseClass.AdjustBitrate(bitrateIncrease_kb_s: integer);
Wrong! Just the mistake I was talking about. You changed the semantics of a method without breaking existing code!
Just think of what is your next task - you have to find all places where AdjustBitrate is called and fix them to pass bitrate increase as a parameter instead of target bitrate. Without the help of the compiler you'll surely miss one or two. True, Ctrl-Shift-Enter (or Search, Find References) in new IDEs can help a lot, but it is still not perfect. It won't show you other projects by your colleagues, which are unaware of this change in the semantics. Or even worse - what if this is a part of some 3rd party library that many other programmers are using? How will you force them all to update?
The answer is simple - your change must break existing code. In this case, the simplest solution is to rename the method:
procedure TBaseClass.AdjustBitrateBy(bitrateIncrease_kb_s: integer);
That's all. The compiler will warn all programmers using your code that AdjustBitrate does not exist and then they'll find AdjustBitrateBy and notice the change in parameters (hope, hope).
Sometimes you're completely sure that no code outside the current project can be using the method you're working on (maybe it is a private method). In that case, I usually rename the method (for example, Add becomes xAdd), fix all call sites for this method (compiler will report errors everywhere I'm trying to use Add), and then rename it back (xAdd -> Add).[