"Give me a work estimate that I like"

I’ve done this dev stuff for a while. I’m old. But it seems in all that time there are two realities that exist for IT projects:

• A blue sky, executive-facing reality, where you’ll get everything you want by summer. Just ask for it! Did you come up with something else? No problem, we’ve got the bandwidth.
• The unspoken slog where weeks melt away, requirements shift, and schedules are distant in the background.

And when you’re given the opportunity to marry these two realities by giving a work estimate, one that accounts for the slog and the blue sky, it’s never neatly accepted in either reality.

• In the blue sky, your estimate is too big! We’re only asking for a simple thing! I have colleagues who’ve built this in less time, and all were happy with the result!
• In the slog, folks don’t pay attention to time. Developers are eternal optimists, and quickly lose track of how long work actually takes to get to prod. We continually forget (or rather, repress?) testing, issues, integration, deployment, and the dark, nebulous region of the unaccounted. (OH yeah, I’m gonna how to rework how all of ‘X’ works to get this in).

…

All this to ask, what is a work estimate? If there isn’t a tedious bean counter watching over hours (like in an agency), should an estimate pretend and make people feel better? Or is it “correct” to plan for the totality of a task, and provide an estimate that gives pause to executives?

Are estimates an art? Are they a statement of a workplace’s culture? What is so damn loaded with using experience to say “X will require Y hours and Z days of work”?

…

I’ll take a breath now.