UPDATE - this was meant to be a reply to the first comment on this post.

What is interesting is to see the results of programs built in the opposite order.

1) Write some code.

2) Write some tests because your users have told you your code is breaking.

3) Write some documentation so your users can understand the app, maintainers can maintain, and you can figure out what you have done here.

This approach is invariably faster to market, and also great a deal more prone to failure and a high incidence of defects. Having used both approaches, I prefer the original order of docs, tests, code, especially when additional requirements arise, because the total cost of development is lower, and the product quality is higher. That documentation is a contract between you and the user.