your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you?

I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid.

in the short term, people will work crazy hours to hit a date if it's the difference between a 7 figure bonus and getting fired. if the estimate is based on devs working reasonable hours, that's a lot of slack built in. I'm sure they hit the date more often than not in your scenario, provided they control most of the dependencies, but it's not a sustainable approach for delivering features.

"provided they control most of the dependencies" is a pretty important caveat by the way. many times I've seen people get the rug pulled out from under them by partner teams at the last second. it doesn't matter how clever you are or how hard you work. if you depend on something owned by a team far away in the org chart, they can always blow up your project with little consequence.

That's an interesting scenario you're proposing.

To answer it personally, which of the two, 7 figure bonus or being fired, it'd be I'd quit. If someone is structuring the development of software based on this premise, then they are going to need a different kind of person than me. But I admit I'm probably an outlier here. I don't really work for the money, and my salary is enough, and I don't like undo pressure.

For arguments sake let's say the 7 figures is $1,000,000. To offer that kind of bonus the project is likely going to be a larger one. And I'm assuming my estimate is determining the deadline, so of course I'm making sure it's something I think I can achieve.

But then there are other significant problems with this structure and the likelihood of meeting the deadline, and, more importantly, generating good code and user experience.

- +5% (in ignoring the -5% as no one cares if you're early unless it creates some sort of QA burden) implies a narrow window. On a 6 month project that is ~6 days. Enough that personnel changes or other uncontrollable factors could lead to a missed deadline. One person getting fed up and leaving would be a huge problem.

- The specification would have to be really clear and agreed upon, since there is much at stake.

- Any changes, scope creep, customer requests, could change the development time, and you'd have to have some sort negotiating buffer built in since there is now so much at stake. Otherwise you're going to get literally everything rejected by the developer as they drive towards the deadline (maybe that's what you want, though).

- Is the result worth having? A focus on a deadline, in my experience, tends to shortchange quality. But maybe the deadline is more important than quality.

- And lastly, if that deadline is missed, or worse, something changes the scope of the project and the bonus is not awarded because that led to the deadline being missed, you're going to have some super pissed developers that will not trust such an arrangement in the future.

I suspect you're talking about situations beyond my pay-grade. I've been a meat and potatoes programmer working in e-commerce and integrations mostly, and we don't see 7 figure bonuses. We certainly have had can't miss deadlines that we mostly didn't miss, but mostly those deadlines were due to external factors (API deprecation mostly), or financial considerations, or lastly, arbitrary deadlines set by management. On the latter, those mostly got missed. But that was to be expected as they were not tied to reality.

And I'd second leetcrews comment below of, "...but it's not a sustainable approach for delivering features". Maybe this scenario works once or twice, but it seems like a terrible way to develop software.

But still, an interesting thought experiment.