[bb88]

> Even bad estimates are better than no estimates.

No estimate is clearly better. Here's a common story I've seen across multiple companies.

1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.

2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate."

3. Engineering management reports to Marketing that coder's estimate leaving off the most important caveat, and Marketing treats that as the gospel truth.

4. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept.

5. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering.

6. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers.

7. This shows up on the coder's annual review who then leaves.

8. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left.

EDIT: The point is that if there's no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.

[karmelapple]

What is plan for the worst in a scenario with literally zero estimate?

“It may take 0 to 3 years” ?

“We literally have no way of knowing?” “Not even a ballpark?” “No.”

This is what you’ve proposed with no estimate, and this seems extremely unhelpful towards the goal of helping all groups at least have some idea when certain “next steps” can be accomplished.

[atoav]

I work as a sound mixer for film and estimating how long it will take is always hard, but I never really got a bad reception when I just said: I canlt tell you unless I see the thing.

Hell if you ask a mechanic to fix your car they will also have to check the thing first before deciding how long it is going to take.

This is the professional thing to do: gauge the situation, take tour time to figure out the scale of the thing as long as you need and then give a pessimistic guess with a disclaimer that things can easily get out of hand without anybodies fault if unforseen problems arise.

[Traster]

Right, but there's a big difference between "Don't estimate until you've done your due diligence" and "Don't estimate".

It's perfectly reasonable to say "This is a big project, it'll take me a week to know where we stand"- there, you've provided an estimate of the scoping task and promised an estimate in the future as well.

[bob33212]

My advice would be to live in the real world. We don't know how long it is going to take. Just like if you go to turn on your car and it doesn't start. Maybe it was a minor issue and the next time you turn the key it will start. Maybe there was a short circuit and the car is totaled. A passenger asking you when you are going to get moving is no help.

[sopooneo]

If your car won’t start, it will take more than a second, but less than a year to fix. That is a bad estimate, but better than no estimate for a space alien that doesn’t know what a car is.

PM’s are space aliens.

[bb88]

The only tool the space alien's PM has is a deadline. "Do X by this date or else." Because he has no hope for understanding the true problem domain before the project deadline -- just like a space alien can't be expected to learn english in 4 days.

A PM with a deep understanding of the software process, can ask insightful questions, identify and possibly mitigate many of the issues beforehand. So when it gets to the software lackeys, many of the resource/architectural issues may have been solved.

[dragonwriter]

> If your car won’t start, it will take more than a second, but less than a year to fix. That is a bad estimate

It's actually a better estimate than most software estimstes, because it isn't just an expected time but a range that results will usually fall within. It would be better if it included an explicit degree of confidence that th actual result would be in the range, and if it was centered around the average time it would take for events in the class.

[Aeolun]

In these cases it’s often a matter of ‘give me a week and I’ll tell you’.

Then again, a similar number of times, the only information you get is ‘we need a chat program, can you please estimate how long that will take?’. Which will leave it forever impossible to estimate.

[notyourday]

> “We literally have no way of knowing?” “Not even a ballpark?” “No.”

That's when the engineering lead or whoever was giving that as the answer is told that his services are no longer required.

[gomox]

Oh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.

[bitwize]

Any decent project manager who wants to keep their job will acquiesce to people further up in the org chart who want deadlines, not estimates, and who consider the difference between the two to be as fuzzy as it needs to be.

[bb88]

> Any decent project manager who wants to keep their job will acquiesce to people further up in the org chart

In my book, that project manager is not "decent". A decent project manager would recognize the situation for what it is and leave.

[Aeolun]

Then there won’t be any good project managers, as I’m fairly certain most executives do this shit.

[bb88]

That's the problem I've been seeing in non tech based companies. IOW when tech isn't what they're selling.

[dragonwriter]

A deadline is a requirement. It is not a PM’s job to reject requirements, though it is their job to help th customer understand and manage resolution of situations where the combination of requirements given are in conflict, such as when a deadline is insufficient to acheive the functional requirements.

[dragonwriter]

And any decent engineering team will accept that a project has deadlines and raise progressively more serious risks with appropriate explanations up the chain as the confidence that completion will occur before the deadline declines below near-certainty.

Deadlines can be legitimate project requirements as much as functional requirements are. Identifying practical conflicts between requirements is part of what an engineering team does. Managing resolution of those once they are identified so that the customer gets the best result achievable is what a PM does.

[rramadass]

>who want deadlines, not estimates, and who consider the difference between the two to be as fuzzy as it needs to be.

This is exactly it. Well said!

[bb88]

There's two issues right?

1. Inability to estimate effort. Admittedly an academic issue, and should be taught to all engineers in college.

2. Inability of management to deal with delays due to bad estimation. This might be caused by a "bozo explosion", say, (where inept managers hire more inept people underneath them.)

Edited to add:

3. Why do we keep making assumptions that management must be infallible? In any dysfunctional organization, it might just take one bad manager high up in the chain that causes pain for the entire organization beneath him.

[redhale]

I cannot believe how much I love the term "bozo explosion". I see this situation all the time as a consultant, and now I have a fantastic term for it. Thanks for sharing!

[bb88]

I'm a consultant as well. You go through enough companies and you can see how much of a problem this actually is.

As much as I did not particularly care for the management style of Steve Jobs, as far as I know, he was the one that first used the term.

https://guykawasaki.com/what-i-learned-from-steve-jobs/

Edited to add:

This just happened recently. Maybe you'll appreciate it.

15 years ago or so (before the term "technical debt" got widespread usage) management kept asking why we working on so many bugs. The solution was to label them as "enhancements".

Just recently within the past year, I saw the exact same thing happen again.

[Aeolun]

> If you ask customers what they want, they will tell you, “Better, faster, and cheaper”

Amazon took that to heart. Seems to have worked out for them.

[krageon]

They did? In what way? When I look at the online ecosystem for buying things in the EU, Amazon is consistently the one that can't promise I will get what I order, can't promise when it will come and can't make it easy to give them money. The only thing they do right is that they're theoretically cheaper, but then because you might get a product that doesn't work (and it's very hard to solve that issue to a standard that you'd expect as someone in the EU) the cost saving benefit goes right out the window.

[gilbetron]

They were the first that made online retail work. Plus there's the whole AWS thing.

[ohithereyou]

I want to work where you do, where friction is negligible, cows are perfectly spherical, wind resistance is never a factor, all functions are continuous and differentiable across their entire domain, and all project managers are decent.

[gomox]

I'm not saying the story is implausible, but I dispute the idea that estimating software development efforts is an intractable problem that is better left unattempted.

[krageon]

Estimating things is important and valuable, but as soon as you get large corporate structures and multiple levels of people communicating involved it becomes a really bad idea. That's why it shouldn't be attempted in those kinds of situations.

[james_s_tayler]

Please don't assume decent project managers. That's how you get in trouble.

[mbesto]

> Hope for the best, plan for the worst.

Oh dear, have you ever spoken to a finance department before?

Here's a common story I've seen across multiple companies[0].

1. The Finance department alots the marketing department with a $500k budget.

2. Marketing department blows through the $500k budget on the engineering department and has no productive app to speak to.

3. The Finance department goes back to the Marketing department asking what happen to all of the money they gave them.

4. The Marketing department says "well engineering told it was agile, which meant they didn't know when it would be done and for how much"

5. Finance department: "Ya, you're not getting a budget ever again from us"

> No estimate is clearly better.

Sorry, but this is not how the real world works. Agile assumes a perpetual budget, which is not realistic for most businesses in the world.

[0] - Personally seen among 100+ and counting.

[Aeolun]

Doesn’t agile presume you have some deliverables every week? At the very least they’d have ‘something’. It might not be fit for purpose, but that should have been fairly visible a ways before they blew through the whole budget.

Unless, you know, there are other systemic issues in the company.

[bb88]

I'm sorry, but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month) then something is more fucked up in that company than what appears on the surface.

But I agree with you, if the engineering management can't budget and prioritize work to get done, that's a larger issue.

[mbesto]

> but if you're spending $500k or more based upon one engineer's "estimate" (for which you're paying $10k/month)

The $500k was just a random number I came up with. Budgets wildly vary based on whether they get allocated weekly/quarterly/yearly/etc. And also it's never "one engineer's estimate", it's usually a project manager who works with N number of engineers to come up with an estimate.

[bb88]

And that's the way it should be.

But keep in mind that if a developer is in a sprint, he might start adding tickets to the epic because of technical/organizational issues. Suddenly the epic might look 3x more work than was originally planned. Note this is not theoretical, as it's happened 3 times to our team already this year.

But meanwhile in the example I gave, the developer gets held accountable still for not making the correct estimate. Management just passes it up the chain rather than trying to increase the confidence around the estimate.

[elindbe2]

It's even worse in my organization. Funding is based on projects so the amount of funding you receive is based on exactly how long your estimate is (if they choose to fund your project). Often projects are estimated based on "here's how much money they are willing to spend, so we'll just figure out the number of man hours that amounts to and give that as an estimate."

[notyourday]

> No estimate is clearly better. Here's a common story I've seen across multiple companies.

As strange as it may sound to developers, the salary is paid by the customers, current or future.

[rubidium]

I’m sorry for your bad experience, but some companies are able to do this well.

[50656E6973]

>1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.

Why can't Marketing just wait until the feature has been built to launch their campaign?

[TheOtherHobbes]

Because campaigns have to be planned ahead too - anywhere between a few weeks and a year or so, depending on the size of the project and the company, and often timed to match big trade events.

And there's always the possibility that if you announce too late competitors will eat your lunch.

One way to handle this is to spend some time on a formal estimate. Two to four weeks of R&D to scope a project can help narrow estimates to something approaching realism. You'll still be wrong, but you're less likely to be hopelessly wrong.

Asking someone for an instant opinion is madness. That's not an informed estimate, it's just a guess, and usually worthless.

[fuzz4lyfe]

Sounds like marketing needs to be agile

[rch]

Because if they launch on the original schedule with Partner X they get Massive Benefit Y that could make or break the product. For example.

[ScottFree]

This. Most developers either don't want to or can't understand that there are real and valid reasons for wanting a predictable software production schedule.

That said, I've only ever seen one software project consistently meet production deadlines. Is there benefit to committing to the original schedule with Partner X if there's no way you can deliver on schedule? Or is it one of those things where Partner X has committed itself and they have no real choice but to work with the sliding deadlines?

[rch]

In the example I'm thinking of the partner wasn't really bothered that the schedule slipped, but the ideal marketing window came and went before the product officially launched, which certainly affected sales. They were really excited that all the planned features made it to market though.

I'd say that some aspects of the capability maturity model make sense, even for engineering groups that practice agile day-to-day.

[ScottFree]

> the ideal marketing window came and went before the product officially launched, which certainly affected sales.

Definitely. I used to see that all the time in the games industry. Getting the right launch window is critical because most of a game's sales happen in the first few days of launch. And yet, games are famous for shipping months, even years late. They usually seem to make it work. I guess you'd be particularly hosed if you couldn't afford the burn rate for the extra X months it would take to get to a decent launch window.

[bb88]

Lots of reasons:

1. Marketing management is full of idiots.

2. The coder's estimate is used to tell the CEO when a product will be rolled out. Who then questions why it didn't get rolled out on time.

3. Marketing gets a bonus for rolling out ad campaigns on time.

4. Marketing is using this for their big trade show coming up and wants to make a big announcement for maximum impact.

Why do you assume management is always competent?

[bobm_kite9]

I think this comes down to the idea that estimates are really for coordination.

At least, I think that’s the best reason for using estimates. I wrote something about this here: https://riskfirst.org/Estimates

[bobm_kite9]

Actually I don’t really understand why all the HN posts on agile just devolve into a discussion about the difficulty of estimating.

Surely there’s more to it than that?

[ahelwer]

Well, standup is also terrible. In addition, there's the general agile assumption that developers are capable of consistently producing X hours of work per day. Maybe it's just me, but I'm a bit more burst-y with my work habits than that.

[majikandy]

I wouldn’t say Standup is terrible but one where you go round the room giving updates is almost useless. It’s not just you, most developers can do 8 hours work in an hour if they aren’t interrupted with meetings.

[Aeolun]

Shouldn’t it average out over 2 weeks?

[ahelwer]

Not if you're doing standup every day and expected to report daily progress.

[jldugger]

Because the superbowl comes once a year -- seasonality matters!