Is it acceptable to make changes to an interface during implementation?

Question

When writing a library/API for the first time I'll usually start by sketching some ideas on a white-board or loose-leaf while thinking about how different parts of the system interact. This usually results in an interface that I'll adhere to when I go to develop some concrete implementation.

I'll get half-way through writing the implementation when I realize that I need to make a change to the interface. For example, I realize that I've exposed too much implementation detail to the client and that the interface can be simplified.

Is this bad-practice, and should I actually know exactly what my interface will look like before I start coding any implementation?

Update

In my situation I'm assuming that the interface doesn't already exist and we're creating it for the first time. So it's the first time that the interface will exist, and we are working on the very first implementation of that interface. So I want to know if in my situation, it's okay to make changes to an interface while coding the implementation.

Answer 1

Yes, it is perfectly fine and normal. It is not really normal to know everything about how your system will work and what it will need to do when you're still in the whiteboard stage.

Answer 2

Changes are inevitable thus they need to be managed.

Make sure to have a clear versioning scheme (search for semantic versioning, for instance), have a very explicit changelog and state clearly what you consider is part of the public API.

For instance, in some cases, adding an optional argument to a function can break backward compatibility if the number of arguments is not expected to change.

Also, there are tools to help you design an API. Test driven development is one of them.