Earlier quoted context omitted.
I went through this. Not sure what toxic culture entails, but fucked up deadlines burned me out. Why do all software companies rush so hard.
There are 2 reasons: 1) Developers cannot reliably estimate software timelines. That often comes with experience and age, but many never learn that skill. It is a skill like programming itself. It comes with practice. 2) Break down in communication between management (product managers) and engineers who are writing code. On the first part. Usually junior software developers simply have not had experience shipping sof…
I'm specifically talking about projects which go like this:
1) A set of high-level business requirements are put together, and given to a tech lead to estimate.
2) The tech lead's estimate, based on the requirements as-given, is used to determine a budget for the project, and probably a schedule as well.
3) Once the budget and schedule are approved, the project commences.
4) As development begins detailed software requirements are worked out, which usually exposes holes in the high-level business requirements that need to be fleshed out as well.
5) The estimates are never updated, and any attempt to increase the budget due to the new requirements are seen as a sign of failure.
What I see happening in #4 is two kinds of scope creep. The first kind is the sort everyone is familiar with: a requirement was missed, a new feature needs to be added, and since this wasn't in the original budget the budget needs to be increased. It's easy to identify these new/changed requirements, easy to see the big chunk of time needed to implement them, and easy to make prioritization decisions about the new requirement vs the other original requirements, so that maybe something can be dropped in order to avoid increasing the budget.
But there's a second kind of scope creep, and it's insidious. It comes from turning high-level requirements into detailed requirements into implemented and tested code. Every decision a developer needs to make about how to implement a feature is an implicit detailed software requirement, and you just can't know how many of those decisions will be needed or what their impacts will be until you get into the details. The time needed for these all add up, and I consider them to be scope creep because they aren't part of the high-level requirements used for the estimate and budget. We try to add padding for them because we know they're going to happen, but if you add sufficient padding across-the-board for all of the detailed requirement decisions that might be needed your project will never get approved. So we pad insufficiently, hoping that some of the requirements will be easier to implement than we estimate to cover the ones that aren't, and we don't manage this kind of scope creep at all. It's invisible, because it's just adding a few minutes here, a few minutes there, until our estimates have been blown away and we're over budget and we can't really say why.