Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more

Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat". The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods. Examples of libraries I've written mostly this way: - https://github.com/franciscop/brownies https://github.com/franciscop/brownies - https://github.com/franciscop/files https://github.com/franciscop/files - https://github.com/franciscop/backblaze https://github.com/franciscop/backblaze