Assuming most HN readers don't need this advice for themselves.
But if you disagree with it or think I left out something important, please consider leaving a reply in the comments on that page, so future readers will see your suggestions, too.
But if you disagree with it or think I left out something important, please consider leaving a reply in the comments on that page, so future readers will see your suggestions, too.
Always have your fights up front, never once the project has started. That way you'll get the project on time and under budget.
I am a little leery of not allowing the developer to provide input though. Things are going to change, you just want to narrow those changes to the important things.
Also, I think it's a good idea to invite feedback. i.e. "Here's the spec, but it's flexible. As you read and develop, be noisy if you have some ideas that could make it better."
A lot of the commenters here are advocating "give devs a vague description of goals and turn them loose". I think that's a pretty bad idea unless the product/problem is a simple/obvious one to solve OR unless the the developer has a good understanding of the market.
But even if the dev is a young superstar who has NO empathy for the customer of your revolutionary manhole cover design workflow software, you should be open to feedback.