There's a discussion of this in Peopleware. If memory serves me well (I read it over 15 years ago), their data suggested that:
1. If you - the manager - set the deadline yourself, the estimate will often be off (unless you're very experienced and could do it yourself; see 3).
2. If you let your engineer set their own deadline, the estimate will often be off (unless they're very experienced; see 3).
3. If you have a very experienced specialist set the deadline, the estimate will often be about right.
4. If you give no deadlines at all ("wake me up when you're done"), directs will pour their soul into it more often than not, and beat the estimate you'd get from 3.
The main argument against 1 and 2 is that having too tight a deadline is very demotivating. What's the point in working against a benchmark you can't possibly meet? (Having too loose a deadline runs into Parkinson's law, but the problem is usually that the estimate is too optimistic.)
Having tried 4 with various teams over the years, I'd suggest it can work wonderfully - but only sometimes. It requires that your team consists a) entirely of professionally minded engineers who b) can see first hand that what they're doing is useful. You're better off sticking with 3 when not.
1. If you - the manager - set the deadline yourself, the estimate will often be off (unless you're very experienced and could do it yourself; see 3).
2. If you let your engineer set their own deadline, the estimate will often be off (unless they're very experienced; see 3).
3. If you have a very experienced specialist set the deadline, the estimate will often be about right.
4. If you give no deadlines at all ("wake me up when you're done"), directs will pour their soul into it more often than not, and beat the estimate you'd get from 3.
The main argument against 1 and 2 is that having too tight a deadline is very demotivating. What's the point in working against a benchmark you can't possibly meet? (Having too loose a deadline runs into Parkinson's law, but the problem is usually that the estimate is too optimistic.)
Having tried 4 with various teams over the years, I'd suggest it can work wonderfully - but only sometimes. It requires that your team consists a) entirely of professionally minded engineers who b) can see first hand that what they're doing is useful. You're better off sticking with 3 when not.