I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works.
Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction.
Often though you can't have your cake and eat it too. There are two schools of thought: worse is better and the right way. The former way eschews simple APIs for simple implementations. The latter is pretty much the opposite.
I'm currently working on a project where I'm trying to maintain a simple API across three different, related services. One of those services has such a simplistic interface that maintaining the simple API that the other two have has made the implementation comparatively complex.
Now I have to take extra care to make it as simple as I can... but it's still complicated. Which means my poor future developer who has to maintain this thing will need lots of documentation in order to understand it (fortunately I maintain TODO lists and notes as I go to accompany my stories... forming a sort of journal of my development process for each project; it makes it easy to pull out useable "how and why" documentation).
No, written tests first means you make the code easy to test. That may make it easy to use to, but it is not likely. Easily testable tends to mean that the class knows to little. And as a user that you have to tell it too much.
The problem is that the worse is better school usually wins over the long run. Jamie Zawinski has a great essay on this [1].
Unix was a "worse is better" MULTICS. DOS was a "worse is better" CP/M. Windows was a "worse is better" MacOS. The advantage of simple implementations is that you can get them in front of users right now, and then iterate your implementation until you have something that's cheap and adequate. Not perfect. Not even great. But adequate. However, as the essay points out, cheap and adequate today beats pricey and perfect tomorrow every time.
Bad example, MacOS was out years before windows. Microsoft just got a massive market hack. It had nothing to do with solving a problem directly and then iterating...
Frankly I think you could make an argument even Win3 wasn't all that much to write home about....
(I confess to still mild incredulity that MacOS beat AmigaOS so thoroughly in the market, being both more expensive and substantially less powerful in both hardware and software. If Commodore had done their jobs properly, we'd be saying Steve Who?)
Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction.
Often though you can't have your cake and eat it too. There are two schools of thought: worse is better and the right way. The former way eschews simple APIs for simple implementations. The latter is pretty much the opposite.
I'm currently working on a project where I'm trying to maintain a simple API across three different, related services. One of those services has such a simplistic interface that maintaining the simple API that the other two have has made the implementation comparatively complex.
Now I have to take extra care to make it as simple as I can... but it's still complicated. Which means my poor future developer who has to maintain this thing will need lots of documentation in order to understand it (fortunately I maintain TODO lists and notes as I go to accompany my stories... forming a sort of journal of my development process for each project; it makes it easy to pull out useable "how and why" documentation).