My problem is with people thinking that estimates are commitments. You just gave me a 30 second elevator pitch on a project you want me to build and I said it's gonna be 3 months? Then you proceeded to scope-creep and delay the project start by 3 months and you're surprised we're not done? Ok then..
I suspect this issue is rooted in human nature aka cognitive biases. I don't stress out about estimates any more. They are just like, my opinion man [0].
And they do that because customers want to know when X is going to be done/fixed.
And pizza analogy is inappropriate. Software development is nothing like making pizza.
For example, if I'm at a point in a project where I need to get a task done:
- The checklist perspective: "Task A must be done."
- But then there's the logical perspective: "How must it be done? There was a recent discussion that affects the process."
- And then there's the time-intuition perspective: "Something is wrong, the discussion included aspects that may alter the way the project is fundamentally designed. If we continue down this path we won't be able to complete the project without a change in approach."
- And then there's the feeling/emotive perspective: "I really hate the way this project keeps changing. It's only fair that we discuss this. Better to discuss it now than later."
- And finally, the checklist calls: "You need a new list for all that new stuff, right? What's the status in making that?"
And these are only _some_ of the perspectives that can complicate things!
Still, it's really helpful to attend to this kind of perspective-integration. Without it, even one outstanding reconciliation can bring things to a sort of inscrutable halt, and _that_ tends to look and feel like unreasonable procrastination.
Plus if anybody mentions the delay, it's easier to make a quick single- or double-perspective decision than to reconcile things in multiple dimensions, which tends to compound the issue but also informs a superior process.
I have some templates I use to work through these kinds of situations, but I'd much rather outsource the alert itself to some external system that doesn't require so much consciousness...
When I worked at a place that normally had 8-hour builds and sometimes had 30-hour builds, it wasn't bad. Building the software could be done a few times per week. That was fine. Start a build when you head home, then expect it done the next morning or the morning after that. You don't need a build for every little change you make. Complete a few dozen bug fixes or features, start a build, and then keep working on more bug fixes and features while the build runs.
It is suggested to not make mistakes. You get to be good at that.
Be thankful you aren't doing hardware, where a build might take weeks and cost millions of dollars.