People don’t intend to make things difficult. It just seems to happen.
"How much work would it be to add auto-scheduling to the appointment calendar?"
"You mean to have the calendar automatically select the next open slot big enough for the appointment?"
"Yeah, that would work."
"Let’s see, I’d have to create a preliminary appointment and then walk through the calendar in chronological order, looking for conflicts with existing appointments. I could do that in a day or two."
"Great, I’ll let my boss know."
And just that simply we have an estimate of how much work it will take to implement this new functionality.
But what is left out of that estimate? There’s nothing in there about controlling the new feature, either through configuration or by the user. There’s probably nothing related to integrating with the existing GUI. It certainly doesn’t account for new discoveries made in the codebase while developing it, or new enhancements that will be desired with it. Nor is there anything for technical dead ends reached while implementing. Or delays due to meetings, other commitments, or lack of availability of the person who can answer questions. It’s just an estimate of the known development work.
Are you done with the appointment auto-scheduling feature?"
"No, the UX designer had some ideas that I hadn’t considered. And the appointment code wasn’t designed to be extendable. It should be done in another week."
"Another week? But you said it would take two days!"
And just like that, a simple estimate got turned into an involuntary commitment.
A single sentence of disappointment from a person with higher positional power in the organization will make that developer think twice before giving an estimate the next time. What might they do in the future?
One possible response is to pad the estimate as a contingency for the unknown. Contingency buffers really belong in the plans, not the estimate. If the estimate is taken as a plan, though, what’s a poor programmer to do?
"How long would it take to add automatically recurring appointments?"
"Hmmm...I could do that in three weeks?
"Three weeks!? My toddler could do it in less time."
A larger than expected estimate often raises fears of sandbagging—that the developer is intentionally estimating pessimistically for their own advantage. And, in this case, it might be quite reasonable for the developer to sandbag the estimate to be sure to meet the expected commitment. Sandbagging doesn’t work so well, though, if it’s not convincing.
Sandbagging is often greeted with negotiation. As soon as there is a counteroffer, you know you’re negotiating rather than estimating.
"How about you do it in one week?"
"I’ll try to get it done in two, but I don’t know what problems will pop up."
Some managers will negotiate estimates as a matter of course, thinking that by putting pressure on the development team they will produce faster. This starts down a very deep rabbit hole of reduced quality, increased defects, burned out development teams, and lack of trust.
