This might come down to a cultural difference or difference in communication styles. As an IC, I'd consider it to be much more honest on my part to be upfront about unknown timelines instead of providing a (quite frankly, useless) estimate just because it's what my manager wants to hear.

At the end of the day, the work will take as long as it takes (managerial interference aside), and I believe in underpromising and overdelivering, precisely to avoid situations where someone's on the hook for an estimate that didn't pan out.

If I wanted my business to be making accurate projections, I'd have been a quant.

When we changed tactics to just asking for an estimation without any direction from us, we would get much more realistic estimates. Took a lot of work to convince our project manager though.

It's something I've struggled to find any good solution for too, particularly if you're looking at work that might take weeks or months because then you're often estimating based off an 'aspirational' and ever-changing specification

Asking for an estimate is often a power play or "microaggression". It's more often about showing dominance than any legitimate business need to know this unknowable quantity. It plays a programmer's present self against her future self.

Her future self wants an accurate or even pessimistic estimate to be made, so there are no unpleasant surprises to management and painful conversations resulting from inflated expectations. But her present self wants the guy standing at her desk to go away so she can get back to work. An unreasonably optimistic estimate gives the powerful, annoying people what they want so they go away. A realistic estimate is going to lead to obnoxious follow-on questions. "Why's it going to take so long?" "I don't know, but experience leads me to think..." "But you see no specific reason why this can't be done in 2 weeks?" "Well, no, because there are unknown unknowns..." "Great! Two weeks!"

This degenerates for two reasons. First, managers tend to believe that, even if overly optimistic estimates are more inaccurate, the work is done more quickly with unreasonable estimates (which become "milestones", then "deadlines"). So they take this as an incentive to be more irritating because it "makes people work faster". Second, it leads to poor planning and brittle schedules and much more undesirable variance.

Obviously, the good software managers don't play these games, but they're probably 1 in 10. Because there is so much money in software, and because programmers refuse to organize and allow themselves to be underpaid, that creates lots of room for mismanagement. Developers are also to blame for some of this; because they've been in mismanaged environments for years, many of them have developed a distrust of management that has led them to miscommunicate and (inappropriately) simplify, hence the "estimates" that evolve into deadlines. Overconfidence and miscommunication are, for sure, substantial components.

True, but there needs to be common understanding that they are estimates, and if the projects take consistently longer, it means the dev is bad at estimating, not bad at writing software[0]. Also, if you get a median time, you'll have, by definition, half the projects taking longer than that; a mean, mode, or 90th estimate will still have plenty of high points; and if you want 100th percentile, you don't even need to ask the developer: "sometime in the next century, probably".

0: They can be that, too, but that's a independent flaw from being bad at estimating.

In a healthy culture it should be possible to have a back and forth about how accurate an estimate is likely to be, but when engineers insist that all estimation is useless you can imagine why other stakeholders may lost trust.

The real problem here is the leadership deficit. The manager got pushback on the estimates, and instead of explaining the reasoning and bargaining on scope, he caved and kicked the can down the road by letting the estimates crumble. Yes, estimating is hard, and you are probably going to be wrong, but once you have your finger on the scale to get a desired result, you can't blame that on the difficulty of estimating. Just deplorable leadership.

The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and headcount you're willing to give, how much tech dept you're willing to take, etc., for the privilege of getting their business.

If you see it for what it really is, you'll see that it works pretty well actually. The business gets more out of you for less to them. It was never about having an accurate timeline or helping with planning or prioritizing, and always about negotiating a better contract with the dev team.

Now keep in mind that the "business" in this case is a person who need to report that through their amazing prowess of administration and management, they personally managed to get X feature out during their last review cycle at Y cost with impact Z. This person will not need to deal with developer satisfaction, retention and performance. They will not need to deal with the impact the lower margins they pushed for had on the next feature delivery, or the continued maintainance of the systems. And if the dev team had to lower the quality too much in order to meet the quote they put out, that will be 100% their fault, the "business" will know not to use them for their next contract, or they'll expect the dev team to take on fixing all the issues at their own expense once more.

That's where it all breaks down. What does "treated accordingly" mean? In reality it means the estimates can't be used for anything because they are always unreliable. There is no such thing as a reliable software estimate, ever, unless what you're doing is so repetitive that you're about to be replaced by AI.

But that's not why people ask. Instead, half the time you give an estimate it gets immediately turned into a deadline, even if you were promised it wouldn't.

The top comment on this thread is naive. The reason devs hate giving estimates or point blank refuse is because it is meaningless, that's not how the software business works. Analogies to plumbers and builders just reinforce the naivety. Guess what, blue collar work is only predictable for as long as it's highly repetitive which being physical in nature, it often is. The moment what you're asking for is "build me an underground railway using the latest technology" it turns out construction estimates are worthless too (see: Crossrail).

One reason tech firms crush their competition so reliably is they don't have an estimates-deadline culture, because they're run from the top by programmers who understand intuitively why they're pointless. Instead developers are incentivized by equity, bonuses etc to do the job as fast as possible.

I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.”

Two years later I learned they were still working to finish it.

Another example: they wanted a Byzantine Fault Tolerance rewrite along with the networking layer. I said we need 6 months. They said we know how it should be done in 1-2 months. I finished my stuff and moved on — they picked couple of people to work on the rest that had said 1-2 months. It took them a year to reach a point they could test it.

Now why did I say 6 above? Because that is a project I have done multiple times, I can do everything in my sleep and the delay beyond all other fundamentals is random interruptions. Did that matter? No.

When top head works with wishful thinking estimates are ways to find scapegoats; nothing more.

In the above case, I didn't get that time I would need, they wanted the estimate to include that time I would need to dig into it. But that's above my estimation powers. I didn't even know if what they asked was possible at all.

They went and asked someone else who did guess some number of weeks, but the work never got priority so we still don't know.

There's a fine line between a manager being understandably frustrated with poor estimates, and a manager being less understandably frustrated they can't pressure you into crunch - but I do draw that line. I find the former completely understandable, the latter completely unreasonable.

There's a similarly fine line between a manager trying to gauge the scope of tasks and help identify unnecessary dead weight that can be cut or delayed, and a manager trying to simply negotiate the estimate down, without cutting anything. The former is reasonable and at times valuable, the latter is either trying to bend the truth to keep their stakeholders 'happy' or pressure games to entice crunch - completely unreasonable - or outright denial (frankly, a failure to do their job right.)

Unfortunately, I think the unreasonable folk ruin it for the reasonable folk, to some degree. Even with managers in the former camp, and with devs I'm convinced recognize their managers as being in the former camp, simply trying to even go through the motions of estimating seem to add a lot of stress and heartache.

Good signs: They point out stuff that's vague, try and actually try to eliminate some of the blind guesswork, helping to produce reasonable estimates, and try to compensate for your bad estimates while guiding you towards making better ones.

Bad signs: They complain about work taking too long, or adjust your estimates down behind your back.

‘we just need a rough estimate, we won’t hold you to it’.

‘Ok based on the 2 minute conversation we just had I think about 3 months’

‘What! That seems way too long’

Other times I’ve been asked for estimates on features even though there is a hard deadline due to some external factor. I really fail to see the point of estimating anything when there is already a decided upon end date. Anyway I usually point out that they will need to just put the features in order of importance and I’ll work down the list. And they should start thinking about what can be cut. This usually leads to protests of ‘we have already cut everything we can’. But I have to laugh as we get closer to the deadline that suddenly not every feature is as important as was originally thought and magically get cut.

What I am saying is that estimates, even wildly incorrect ones, are over-valued and over-used. You seem to agree with that.

I was pretty self-conscious (still am) in why do I mis-estimate but truth be told, nothing much can be done most of the time. If you go the cautious route, management tells you "that's too long, reduce it". If you reduce it, it's very likely you'll miss that now imaginary estimate, and the whole thing restarts itself for yet another vicious cycle.

If you overwork yourself and manage to meet the near-impossible deadline, this becomes the baseline expectation for your productivity. One you cannot maintain for long. Yet again, management is unhappy afterwards.

All of what you said I can easily agree with... if we the programmers had actual decision power in the managerial hierarchy. Which we don't.

Who wants a product that was rushed? If there’s not enough time, cut scope.

As a Project/product/eng manager, it’s my job to buy time, hit the dates I set, and make my boss more $$$. If I’m saying stuff like “a month is too long; you have until Friday,” I screwed something up or got screwed by someone else. Regardless, the engineers should leave because it’ll keep happening.

Big projects can suffer from this because little architecture is involved (and we worked on already existing systems). Otoh, I’ve seen no big local project that wasn’t an architectural mess once it hit a deadline hard. It is better to not have one than to have a set of rules that you must obey, while other parts of system don’t even care of or contradict these.

Personally I don’t believe this “I’ll get back to you with an estimate” thing. It is just first iteration where you go relax and try to formulate at least 5-10 questions that you think you should ask foremost to start building an estimate. If you come back with an answer instead, then it is still wrong, maybe even worse than random, since you estimated a different thing. For us, estimates and requirements always moved, as they were functions of delays and business priorities that change unpredictably. I didn’t like to deliver the entirety on a deadline because my job was to support that for years, not throw a bill at them and run, as all integrators did.

Maybe, maybe these SE-users are speaking about coding phase, when all “business analysis” was done perfectly. But ime it is you coder who collects all the knowledge, because no one can. Or it is you who is non-coding analyst who must estimate, because non-analytic coders don’t have a clue what a big picture is.

Granted, newer programmers are bad at estimating these sorts of systematic overheads. But people get better at estimating as they gain experience. One root problem that never goes away is that the people who want the estimates don't often want to hear about a cost that can't be broken down by line-item and individually justified. An answer of "it's going to take twice as long as we think", however true, rarely satisfies a manager.

The estimates aggregate to a number more accurate than each individual. The manager cares more about the sum total than each individual one. Many can even slip without affecting the end date.

This isn't so hard, if management and developers didn't treat each other as enemies. Each can get wrapped around the axle concerning each deadline, rather than the real goal of allocating resources across the entire scope.