There comes a time in a project's life cycle, especially an API, when a bunch of cruft builds up around it. The more poorly directed development is, the quicker this happens (pretty much it's happening immediately, also don't be upset if your project has cruft to it, it happens to pretty much everyone). The more developers there are, the more cruft there is.
It's all about predicting the future, and programmers think they can. They are so clever they know exactly what their scope document says, exactly what the client really wants, and exactly how to implement it. At least I'm fairly sure that I know all these things.
Regardless of who knows what, oversight must be maintained. At the top of a pyramid (gaggle) of hackers, there is usually a sighted one. Someone with a bit of vision. Sometimes the hacker themselves, upon reflection, gets this vision. Perhaps the guy with the eyes might say these things:
1). The work flows are more valuable than the code. This, I think, is the most important of the rules. You're a human being, so you're learning. Some projects are just too huge to start throwing away components here and there, but to lug your huge API with you from project to project is bondage you don't need.
2). Don't be afraid to re-invent small wheels. Don't write 10 lines of code to avoid re-writing 2 so you can write 4. None of you are so good that you don't need to perform what I'll call "vengeful refactoring" or "omega-violent refactoring" every once in a while. Take no prisoners. Your future self will thank you.
3). Re-assess external technologies regularly and often. There are several developers out there writing software for free. It's being milled about in the washing machine of the internet all day every day, and all night because of foreign hackers and red bull. This stuff is _good_. Some of it is poorly documented, and that makes it is safe to ignore. But all the good shit with good documentation, seek it out, and use it.
4). Sometimes a great work flow is stumbled upon by accident, usually while someone was writing bad code. Don't be afraid to throw away that code, the worst that can happen is a better understanding of the process behind it.
5). Your API is as good as it's consistency in convention & its documentation. Think jQuery vs. Prototype... Use this measure when trying to figure out if you should toss your API. Nuff said here.