Very true, I think those estimates are actually two ideas/types crammed into one value.
1. The construction part, as you said, can be estimated.
2. I'd just call the other thing "allocated time" instead of "estimated time".
Any time someone asks me how long it will take me to fix a bug that I haven't really looked at yet, or to plan some new feature or something like that, and they badly need a number, I ask them how much time I should allocate to that. I can't promise to have something like that done by that time, but it gives us both an idea about how to treat that problem.
For example, we could allocate two hours to fix a bug, with the understanding that if that turns out to not be enough then we'll need to talk about workarounds. Or we can allocate two days to plan a new feature, and the best solution we can think of in that time shall be the one we use.
This is brilliantly put. That's pretty much what engineering is – constraints and tradeoffs – giving software project planning/execution a healthy vocabulary to talk about makes it so much better. Much of the crappy feeling that developers go through by putting themselves into a corner can be avoided if everyone had better mental/language models to think/talk about it.
1. The construction part, as you said, can be estimated.
2. I'd just call the other thing "allocated time" instead of "estimated time".
Any time someone asks me how long it will take me to fix a bug that I haven't really looked at yet, or to plan some new feature or something like that, and they badly need a number, I ask them how much time I should allocate to that. I can't promise to have something like that done by that time, but it gives us both an idea about how to treat that problem.
For example, we could allocate two hours to fix a bug, with the understanding that if that turns out to not be enough then we'll need to talk about workarounds. Or we can allocate two days to plan a new feature, and the best solution we can think of in that time shall be the one we use.