Skip to main content
Software Engineering

Return to Question

http://meta.programmers.stackexchange.com/questions/7285/structured-tag-cleanup-initiative-phase-ii
Link
gnat
gnat
  • 20.8k
  • 29
  • 115
  • 295
Post Closed as "Not suitable for this site" by ratchet freak, durron597, user22815, user53019, user40980
Post Made Community Wiki by brmore
Tweeted twitter.com/#!/StackProgrammer/status/131420278533259264
added 165 characters in body
Source Link
Shawn D.
Shawn D.
  • 1.4k
  • 1
  • 12
  • 14

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.

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.

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.

Source Link
Shawn D.
Shawn D.
  • 1.4k
  • 1
  • 12
  • 14

Is there a way to combat Sales perpetually overcommitting?

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.