So why would you write code that you may or even will change at a later date. There are several reasons to do so:

• prototyping: It will give your client an early idea of what the system will become
• project overview: It will give you as the developer a clear overview of what the application will look like
• unclear specs: You create a mock class/method because you want to implement the call while the actual functionality is not yet clear

Let's have a look at these.

Prototyping
Most developers will have some experience with a project that was delivered right before the deadline, only to have the client tell you that it's absolutely nothing like what they needed. Even though correctly describing the product in a functional and technical design before implementing it is good practice, often the client will not know exactly what they want until they see something. Therefore, it does not hurt to have prototypes of the functionality you want early in the project. You will get early feedback and can make adjustments to the system in early stages. In a prototype your code does not yet need to be completely optimized and perfect. It needs to give your client an idea of what is coming. Once your client approves of a certain implementation, you can start optimizing your code.

Project Overview
To get a good overview of the project from a technical standpoint, writing a global overview of your code to start with will give you a better idea of your project. You can start with dummy code or very simplified code, and then refactor each piece to get the actual functionality. The great thing about this is that early in the project, you get a good overview of the application you're building and its technical structure, and you will be able to recognize early on that a certain approach will not work. Since you did not spend a lot of time on building that first, you will actually save time here! You just implement your new approach (in dummy code first if you want) and see if that works for your needs.

Unclear Specs
When you are doing a project, it may happen that certain parts of your functionality are not fully specified yet. However, other code may rely on this particular bit, so you want to build in the call early. This problem is easily solved by actually writing the class or method, however not implementing any actual functionality in it yet. Just return true or false (if a boolean is expected), or a dummy value in the type of return value you expect. Once the specifications are more clear, you can go back to this piece of code and implement the functionality according to the specs without either having the delay of waiting on these clear specs, or having to implement the calls to this code in all the places it was missing.

A waste of time?
Given the above, perhaps doing some refactoring every once in a while isn't that horrible an idea. Even writing code with the explicit purpose of being refactored later may not actually be a waste of time, but a time-saver!