Thanks! Every company occasionally has reason to cut some corners and deliver early. Some thoughts on that:
1) Most deadlines are imaginary. It's very likely that even if you hit your deadline, you'll find out that most of the stakeholders have already changed direction or don't care that much. It's unfortunate, but that's been my experience.
2) A true high-stakes deadline should only come up a few times a year. If it's more often than that, constant death marches won't help -- it's an organizational issue, probably stemming from issues in management. Lobby for change, and if change doesn't occur, start looking for another job.
3) Constant pressure to deliver will slow down development in the long run. It's death by a thousand cuts. A company that can't take a sprint or two to clean up the code and build a strong foundation for faster development later will eventually end up in a slog, developing so slowly that they might as well be moving backwards.
4) Know what corners to cut, and expect management to cut some of theirs as well. Refactoring can often be left for later; testing often can not. Make sure the gray suits understand what demands create the greatest burden and ask them to compromise.
Hope that helps!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks! Every company occasionally has reason to cut some corners and deliver early. Some thoughts on that:
1) Most deadlines are imaginary. It's very likely that even if you hit your deadline, you'll find out that most of the stakeholders have already changed direction or don't care that much. It's unfortunate, but that's been my experience.
2) A true high-stakes deadline should only come up a few times a year. If it's more often than that, constant death marches won't help -- it's an organizational issue, probably stemming from issues in management. Lobby for change, and if change doesn't occur, start looking for another job.
3) Constant pressure to deliver will slow down development in the long run. It's death by a thousand cuts. A company that can't take a sprint or two to clean up the code and build a strong foundation for faster development later will eventually end up in a slog, developing so slowly that they might as well be moving backwards.
4) Know what corners to cut, and expect management to cut some of theirs as well. Refactoring can often be left for later; testing often can not. Make sure the gray suits understand what demands create the greatest burden and ask them to compromise.
Hope that helps!