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: 
> 
> **In general, is there a way to push back on this?** If not for this release, what about in future? 
> 
> 
> 

Of course, there is: Let them ***fail*** badly with this approach. ***Nothing teaches as well as failing.*** 

Make an ***estimation*** yourself before you start and ***show it*** to them. Then do your best, write good code, stop ***compensating*** for their stupidity with your free time, and when they complain afterwards, ***remind them*** of the time estimation you had shown them, based on engineering principles. 

And you better start doing this with the *current* project. 

If they keep blaming you for the problem, you'd better start hunting for a new job, since nothing will convince them that they are the problem. 

As an afterthought, I think this question actually warrants a link to the famous EA story as featured in one of Joel's books: ***[EA: The Human Story](http://ea-spouse.livejournal.com/274.html)***.
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.