The phrase 'eating your own dog food' is an interesting one admittedly, but it conjures up the right imagery when it comes to ensuring that our APIs are suited for the stated purpose. We should consider it a fundamental failing of our development process if we aren't the first customers of our libraries, and this should begin well in advance of our libraries being made publicly available. Ideally this would be an ongoing process throughout the development of our library.
It is important that we accept however that we are not the best testers of our software, because we carry with us intimate knowledge of the problem domain, as well as how our library works to represent this. We need to find people less familiar with the problem domain and our code. These might be people on adjacent teams to ourselves, or friendly customers who are happy to give us honest feedback.
We need to discern two things from these studies with developers who are unfamiliar with our API:
- Can the user perform the tasks that the API sets out to enable?
- Is our API concise, or does our user find themselves struggling with an overwhelming morass of API that goes beyond the stated purpose of our library? In other words, have we failed to be restrained?