Question: I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then. Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything. 

**In general, is there a way to push back on this?** If not for this release, what about in future? The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.

Answer: 
This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP features and delivery date (in terms of being earlier). They will push those as high as they can in order to close the deal. 

Try and see it from their point of view, just for a moment. They've got a family to feed, too - and if the difference between closing a sale I've been working on for months is just trimming off a few weeks of the schedule, then it's an incredible temptation, especially if I don't really understand what that means.

The temptation is to say "twas always thus, and always thus will be." But one place I worked did at least have a solution PROPOSED, if not implemented...one manager finally threw up his hands and said, "if the programmers' overtime is being used to close a sale, then they should receive a portion of the commission." It wasn't implemented, but it would have aligned everybody's incentives more closely...the programmers would have been thrilled to hear about a new feature that had to come out in no time, because they'd be anticipating the commission, and the salespeople would be LESS apt to create those circumstances, because they would be less likely to work to their advantage.
It's hard to answer without knowing your company structure.

Some general tools to help are:

* Have agree upon (but those in charge, not sales) quality controls
* Have a product roadmap (internal and external)

By having agreed upon **quality controls**, you have a business-driven reason for not being able to release buggy software. You might need to convince your bosses why this is important (hopefully not), but there is plenty of literature out there to aid in this.

By having a **product roadmap**, Sales know what they can and cannot promise to customers. If they want to change the roadmap, they have to raise it with the Product Manager/Project Manager/ Development Manager or whoever else is in change of it.

If they promise something to a customer that hasn't already being agreed to, tough luck. Hopefully your roadmap is based upon **market data** on customer needs. "What exactly do you propose we drop from these 8 other high priority features that we have evidence our customer base needs?"

Last of all, as already expected, don't work 80 hour weeks. You aren't even helping the company by doing that because you are just aiding them in digging a deeper hole.