One advice in this pdf is that on designing first before implementing. I think iterative cycles of design / implement / use / design /implement use yield better results.
Iterative cycles take advantage of the regularity of change. APIs shouldn't change once public, hence the emphasis on Big Upfront Design. However, change still needs to happen so versioning comes into play.
Personally, when it comes to APIs, you can tell those that have been designed upfront rather than iteratively; they are generally better IMHO.
The API that appears to be well-designed up front was probably preceded by many not as great APIs either done by the same designers, or that could at least be learnt from. That is still quite iterative, just in the long term sense. Real waterfalls don't exist.
If you have an API that does something well known, find and learn from existing APIs that do that. If not, then he prepared for lots of trial and error, scenarios you didn't think of, and so on. It might make sense to put out a "worse is better" API first so the learning and feedback loops can start.
What I would advice is to design the API (public part) without considering the internal code (private part).
We often change our point of view on how to solve a problem (private part), but rarely the problem itself changes (public part).
Iterate away your (internal) architecture as much as you want, but when dealing with the API (your external world interface) make sure to put yourself in your user shoes.
One advice in this pdf is that on designing first before implementing. I think iterative cycles of design / implement / use / design /implement use yield better results.