Why do developers deliberately give bad estimates?
Specifically, the person asking this on LinkedIn was talking about estimates that were deliberately too low.
One reply indicated that developers are lucky if they are asked for estimates at all. It's true. I've been handed absurd, inflexible due dates over the years.
I would have added a comment about why developers might deliberately provide a low estimate, but someone else beat me to it.
So I was about to move on, when I noticed that there was also a comment suggesting that developers sometimes deliberately overestimate. That comment raised some red flags for me.
I'll come back to those red flags in a bit. First, let's talk about underestimating.
Why deliberately underestimate?
I had an argument about this with a colleague once. He was in favor of giving management the shorter, unrealistic estimate management wanted to hear.
His reasoning: why upset management with a high estimate? You know your boss doesn't want to hear "three months." Make them happy. Tell them it will take two.
Then, in a month and a half, say, "we'll need an additional month." Management will just shrug and accept the new estimate.
I winced. Aside from the fact that it's wrong, it's a compelling argument. Yes, management will like the shorter estimate. And they will likely not flinch when the project runs over. They're used to things running over.
And why are they used to missing deadlines? Because people keep giving them the shorter estimates they want to hear. Bogus estimates, my colleague said, are expected. Just part of the game.
Real estimates, please
Let's stop playing this game. It's garbage. You give yourself a reputation as an unreliable estimator. Your management is also lying, knowingly or not, to stakeholders. Smells like danger to me.
Give real estimates. But do the work to be ready to back up your claims.
Side note: avoid "ballpark" or "gut feeling" estimates. No matter how much you emphasize that this is "off the cuff," or how much people tell you "I won't hold you to it," others still hear them as commitments. And without the research, you can't back up your claims.
If you can back up your claims, that's good. Then, when your management objects to your short timeline, you can explain precisely, with data, where your estimate comes from.
In response, the boss might...
- Make reasonable changes. "Okay, if we postpone feature X, and I take project Y off your plate, can you do it by the end of September?" Maybe that works.
- Make (possibly) unreasonable changes. "Come on! You can do feature X in a week! Not two months." Even if it seems outrageous, discuss it. Why do they think that? What do you know that they don't—or vice versa?
- Reluctantly agree with your reasoning. Great! The timeline might be uncomfortable, but it's realistic, and you're both on board with it.
Or, your management might overrule you. Ouch. They might set an unreasonable timeline, and make no compensating plan to handle it.
That's awkward, but hey, managers get to do that. They're allowed to make decisions that go against your incredibly brilliant and wise advice.
Who knows, maybe they have good reasons they can't share. Maybe they don't. Either way, it's their prerogative.
Just be aware of how it might affect you. Will you take the heat for a late delivery? On a scale from "nobody notices" to "scapegoats get fired," how big a deal is a missed deadline? What has happened in the past when targets are not hit?
What about deliberately overestimating?
The comment that sent up red flags for me: developers who "don't want to" do something will deliberately overestimate it as a way of dodging it.
Red flag number one: don't want to.
The person making this claim gave an example. A developer once gave them a two month estimate for something. The commenter thought that it could be done in a week. Out of frustration, the commenter worked on the weekend and got it done.
Red flag number two: on the weekend.
What developers want
In my experience, what developers "want to do" is primarily what their management wants them to accomplish.
Sure, you might prefer to play with cool technology, or do easy or fun work. Ultimately, though, you need to get stuff done that aligns with your management's priorities. If you don't, you won't be around long.
Was the commenter in this developer's management chain? If yes: they should ask the developer to explain the long estimate. If needed, they can clarify priorities. "This is more important than project Y. Put Y on hold."
If the commenter was not in the developer's management chain... well. Here's how it has worked in my experience:
I learn my team's priorities from my manager. Let's say the top priorities are ranked, 1-14. If you're not in my management chain, your request is in slot 15, at the earliest.
If you want to jump the queue, you might convince me to advocate for you to my management. You're better off making your case directly to my management.
For that matter, if you're outside of my management chain, I shouldn't even give you an estimate. Not without conferring with my management about how they would prioritize your request. Promises made without checking first can work out badly for everyone.
How developers work
Is this the fantasy about how developers work?
- As a developer, I work on one thing at a time.
- I sit at my computer and type code for a few hours.
- Once it works, that thing is done! Yay!
- I get a kombucha from the tap, shoot some pool, watch cat videos, whatever. It's great to be a developer.
- Eventually I choose a new thing to work on, and... repeat.
Trying not to laugh out loud here in the cafe.
One thing at a time? Uninterrupted coding time? A few hours?? Oh, how wonderful that would be!
I wish we all worked like that. Yes, let's break work down into small chunks. Focus on just one piece until it's done. Glorious!
Alas, we are not so enlightened as a society. Reality looks more like this:
- While I'm coding one thing, I'm juggling several others: troubleshooting, answering questions, helping a colleague, discussing requirements, and so on. Then there are staff meetings, mandatory trainings, "quick" questions, email, emotional first aid for colleagues in distress, administrative tasks...
- Those rare small items—needing only a few hours of focused coding—can therefore take days.
- Coding itself is rarely straightforward. Requirements are problematic. Surprises and detours lurk in the code. A typo that I'm not spotting can derail me for an hour.
- Even when I'm done, things are rarely done for good. They boomerang back to me for more work.
- No kombucha on tap, but there's candy in the kitchenette. That's good, because I worked through lunch again. It was the only time I could concentrate.
So, it isn't like the daydream version.
If we really did work like that daydream, though? What audacity I'd need to estimate two months if I just needed a few hours of uninterrupted coding time!
When would I get time like that?
It's no huge surprise to me that the commenter complaining about the overestimate was able to get something done on the weekend. Presto. Time to focus only on that one task.
Renegades
Furthermore, I have some questions about how well the task got done. If this person needed to ask a developer for help, it suggests to me that they don't normally code in that codebase. Another red flag.
A renegade coder can get things done fast. Ignoring pesky things like security, unit tests, coding standards, edge cases... you can get something "done" much faster. And you might not be around to see the amount of chaos and rework your code has introduced.
Is it deliberate?
Question for people who have had developers "deliberately" provide bad estimates. How did you know it was deliberate?
Did the developer say so? "I only said two months to make you happy (or to make you go away)."
Did you do your own estimate? If so, did you discuss your estimate with the developer to find out why you came to a different conclusion?
Did you decide the estimate must have been deliberately wrong based on the end result? Maybe your reaction was: "See? They can do it faster if I push them." Or maybe: "See? They always take longer than they say they will."
Hmm. Is "pushing" just an inelegant way of changing or clarifying priorities? Is the developer dropping your previous "top priority" to work on the new "top priority"?
Or, if the estimate was too low: is it safe for a developer to give you a higher estimate? Are you likely to lose your cool—or overrule them—if you don't want to hear it?
If you're not the boss, should you even get an estimate from the developer? Maybe their boss has other ideas.
Another possibility: was the developer just inexperienced? Consider this:
How long does it take to drive from point A to point B? A new driver might guess based only on distance. A more experienced driver might consider traffic, road speed, and weather. Construction or an accident can throw off even the best estimates.
Same with software development estimates. The more experienced you are, the more accurate your estimates are likely to be.
All of this makes me wonder how many incorrect estimates weren't deliberately wrong after all.
Drop me a note
This was a long one! And I didn't interrupt it with Unsplash images. I don't know if "no images" makes it better or worse. Thanks for reading.
My husband referred to "Lululemon" with the emojis 🚽🚽🍋, and I was then definitely laughing out loud in the cafe.
I would love to hear from you. Hit reply and let me know what's on your mind.
This newsletter is approximately weekly. In addition, I post to my blog on my website, which is mirrored to Medium and Substack.
Most recent blog post is on pressure and resistance. Want to start (or stop) getting blog posts by email in addition to the newsletter? Edit your preferences here.
Know someone else who would enjoy this? They can subscribe here: https://www.beyondwritingcode.com/connect/
Thanks for reading!