Heh... you've gotten really good at hitting "hot spots" for me in your articles, Andy. :-D
Unless you're the project manager, there's no way to reduce this type of stress other than to realize there's nothing you can do about it except report the reasons correctly and without emotion. People always wait until the last minute or some teams do a less than stellar interpretation of the requirements they've been given which requires rework and the resulting stress that causes.
When a project is being put together, people need to realize that there aren't "different" teams. There's only one "project team" and the individuals and groups in that team need to work together and keep each other informed about the project on all fronts... especially if you have a less than stellar project manager. ;-)
I am, by no means, suggesting an "it's not my job" attitude (which becomes self-prophesizing at times). For a team to perform and perform without stress, the component parts of that team must constantly and effectively interact on a daily or even by-the-minute basis. There is no stress in a well-oiled machine that's running on-time. :-)
I'll also say that stress in a project is normally and unwittingly a "planned" thing because most managers don't plan for contingencies that will take extra time or even add scope to the things that need to be done. The old saying of "failure to properly plan is planning to fail" has a lot of merit to it.
That includes the "worker bees", as well. Many developers (front-end and back-end) will "plan" their own priorities in the project along with other projects (and ad hoc tasks they're given every day) they may be working on and they usually grossly under-estimate what actually needs to be done and the time it will take. By the time they get around to working on "the project", it's already too late to have any chance to properly meet the actual deadline. As a result, they end up taking huge shortcuts just to "get things off their plate" and it fails in test which requires still more time in the form of rework and you end up with totally-crap-code and a death spiral of rework (along with the related stress) in the project.
Right after all of that, a new form of stress arises... the stress of having a totally pissed-off customer because either the code doesn't work correctly or doesn't scale to meet their needs. Reworking that, of course, causes additional stress because the deadlines for all the other poorly planned or poorly controlled projects have deadlines looming, as well.:-P
This vicious cycle of stess can be broken but it takes everyone to do so. Managers need to stop making silly, uninformed promises as to when something might be done and they need to build in some contingency time for things that (it seems and therefore should be anticipated) WILL go "bump" in the night during development, testing, and deployment.
Project Managers need to do the same and they also need to learn that things are easier to say than do. It's not that Developers intentionally lie... they just underestimate especially when under pressure to meet a deadline (no one wants to admit to something that will take longer than the given deadline). Developers need to understand that things will go wrong and provide estimates that have contingencies identified ("If we don't have data to work with to test for scalability, we'll need to build code that builds adequate test data.", etc).
Developers also need to properly test (happy-path, unhappy-path, performance, scalability) their own code because it's much easier and much more time effecient for a Developer to catch his/her own mistakes rather than starting the horrible "rework after test" cycle which can take a whole lot more time than simply taking the time to do it right the first time. That also means that a Developer must have an absolutely clear understanding of not only the requirements of the code they're writing, but what the process that uses the results from that code will be doing.
I know... I know. The thought that most folks will have after reading all that will be "Jeff... You're talking about a perfect world that will never happen." That would be another of those self-prophesizing statements.
You've got to start somewhere because if no one starts to make a change, then you're right... it'll never happen. :-P And, yes, I have seen what happens when "the Team" get's it all right... early and less costly developent and deployment, much less stress, and 40 hour work weeks for everyone.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs