“When is it going to be done?” is a reasonable question and we as software developers should try to come up with the best answer we can based on our experience and analysis. What we should not do, however, is treat our answer as solemn oath.
When you treat estimates as promises instead of guesses, you bind your worth as a worker to it. If you do not meet your own deadline, you are a failure. And since nobody likes to be a failure, they’ll indulge in risky behavior to avoid it, like burning the midnight oil and checking in bad code with scanty or no tests.
Rushing to meet your estimate promise once or twice might be bearable, but it’s ultimately unsustainable. Software development is inherently unpredictable. There are just too many moving parts and ice tips that turn out to be icebergs.
If you treat the estimate as a “best guess based on the limited information available to me before I start the work”, though, you’ll change the frame and break the cycle of deadline anguish. Now the task becomes collaborative and you can share new discoveries with the stakeholders.
Found out that doing the feature as originally designed requires changing some fundamental infrastructure that’ll add another two days to your one day estimate? Maybe it’s not worth it any more. Ask the stakeholder if he’s still interested in the feature when it costs three days instead of one. Or if there’s a way to simplify it such that the infrastructure change is not necessary.
That’s the true value of estimates. That it sets up conversational constraints that can be used as boundaries for trading concessions. Not that they’re nails for your own self-erected cross.