[dkarl]

a) Nobody can be "given" the chance to estimate accurately. Either you already know the code and know exactly what you're going to do, or you're just guessing, hoping that the task will prove similar to something you've done in the past.

b) People are used to being lied to about criticality, and "understanding" the criticality of deadlines is usually code for working extra hard to compensate for planning mistakes, unplanned work, or other people's mistakes. The willingness of developers to work unpaid overtime to meet deadlines should be marveled at and appreciated. It's not like we're respected as professional-class people (doctors, lawyers, etc.) We're just "resources" who are usually suckers enough to work unpaid overtime when needed. Don't complain when we actually do the sensible thing and leave at 6pm.

c) Putting in a fair work week and hitting internal milestones "from day one" are not the same thing.

d) Good managers stay in touch. It's part of the job. Just accept it.

[param]

Agreed. You may want to see another comment I've made where I would be ok if they can explain the delay with a valid reason for it - personal reasons/infrastructure issues/unexpected complexity.

The basic point you are making is that if there are unplanned/under-planned developments, we need to account for them in a way that's humane, rather than forcing the developer to hold on to an arbitrarily identified date. I am all for it, but in my case, I am not getting any good reason for the delay, just a note that things are delayed.