Hacker News Reader

Comment by xwdv | Hacker News Reader

No.

Even bad estimates are better than no estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates.

You must never turn estimates into a promise, always remind people they are estimates.

Want to give fast estimates? Here’s how:

1) first determine the scale of the task? Is it a year, month, week or day kind of task?

2) Then, it’s just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it.

I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won’t take more than a day.

View on HN

> 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.

>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?

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?

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.

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?

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.

> 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.

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

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?

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.

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.

Shouldn’t it average out over 2 weeks?

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

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.

Sounds like marketing needs to be agile

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

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.

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.

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.

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.

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.

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!

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.

> 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.

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.

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

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.

> 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.

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

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

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.

>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!

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.

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

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

> 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.

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.

> 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.

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.

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.

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.

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.

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.

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.

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.

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.

> 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.

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.

> “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.

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."

> 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.

> You must never turn estimates into a promise,

Whoever asked you for that estimate will do that for you…

> always remind people they are estimates.

…even if you remind them. I mean, the reasonable ones won't, but many people aren't that reasonable.

I've been in an interview last week where they told me the teams were strongly committed to the features they planned to do each sprint. Which I interpreted to mean that their estimates are promises.

> Want to give fast estimates? Here’s how:

My, this looks like it could actually work. I'm going to try it right away.

It’s funny because even with capital a Agile / Scrum, in 2011 the term commitment got changed to forecast [1]. But then many companies who are dogmatic about Agile still use estimates as commitments anyway. That makes technical debt really hard to avoid... One solution is to create technical debt tickets in the backlog so people become aware of it.

1. https://www.scrum.org/resources/commitment-vs-forecast

>Even bad estimates are better than no estimates

Absolutely not! An estimate should not be a random number but should be constrained with available data however small it might be. If you feel that you don't have enough to form a "guesstimate" do not give me a number but first work on finding the data which will enable you to form a proper estimate.

Once you give an estimate, no matter how many times you explain that it is a "guesstimate" people tend to lock on to the given number. It then becomes a real battle trying to explain the hurdles (and there are always some unknowns) while revising the original estimate. Soon mutual distrust develops between the implementation engineers (stressful and detrimental to actual execution) and the management leading to everybody losing faith in estimates. Agile/Scrum have exacerbated the problem with their short time windows and sprints. In one team that i was on, people just gave up and started quoting 2 weeks for any and every feature, trivial or non-trivial and the whole exercise became meaningless.

PS: The book "How to Measure Anything: Finding the Value of Intangibles in Business" is worth reading to get some ideas on how one might do proper estimation.

> You must never turn estimates into a promise, always remind people they are estimates.

The person giving the estimate isn't the one who does this. Other people turn them into promises, because that's what they were actually asking for when they asked for "an estimate".

Giving some kind of uselessly vague estimate isn't particularly useful from an engineering perspective and everyone else has been trained by scrum the last decade to treat them as promises. So don't do the thing that you know will have a bad effect.

> The person giving the estimate isn't the one who does this. Other people turn them into promises,

Why is that your problem? If someone tried to hold me to such an estimate, I would simply say "I never promised this, in fact I explicitly didn't promise this. I'm sorry X lied to your face about this." Don't own other people's failures.

> Even bad estimates are better than no estimates.

I disagree. The only bad estimates that are ok have to error on the high side. I have found that biz side may not like the longer estimate, but they much prefer that over missing a date.

Right. If they asked for a 95% confidence number, they would get something to depend on more whole heartedly. But that date will be too far in the future to be comfortable.

So they look for more of a natural median. And then are shocked when dates are missed more than half of the time (!).

So if you want honesty, ask for estimate ranges or 95% sure estimates. Then pareto your plan to hell and back so everyone understands the risk. Then reestimate periodically as you home in on completion.

Great you know how you work best.

There are other ways. The best of humanity have a wide range of methods they use to get shit done at a level most of us dream of.

So I have a hard time taking a straight jacket process like you suggest as some sort of panacea. It’s essentially another manifesto. What’s the expiration date on this.

Everyone goes on about the value of writing less code, and here we are incentivizing manufacturing line processes for crafting more code?

Note the authors of things like the Phoenix Project: rich Silicon Valley types. We’re just discussing how to be better assembly line workers for tech aristocracy.

Figure out how to build your business in such a way it works for the business. Google didn’t get big because it has perfect process; it can and often is a mess. It got big solving it’s problems and monetizing the solution (every company will need to search for digital files, send email, edit docs, etc).

Figure yourself out, compare with others. There’s is no one size fits all to thinking about problems and even the biggest winners don’t have all the customers there is. Why isn’t Gmail the only email solution?

There’s never a perfect process.

I do something similar, except don't assign to a number. My back of the envelope estimates are: hours, days, weeks, months.

This gives people enough information as to whether or not a change is worth it. If the difference between, say, 2 and 5 days makes or breaks the feature it's probably not worth exploring in the first place.

>You must never turn estimates into a promise, always remind people they are estimates.

Herein lies the problem. Many companies that do "Agile" fail to realise that estimates are just guesses, they're not accurate and yet, the issue is companies taking these estimates and holding developers to them. That's the real problem.

It's all well and good to say, remind people they're only estimates, but many of us who have been in this industry longer than a minute knows that estimates nine times out of ten are taken as promises and that's when we get crunch and burnout as developers are forced to achieve the impossible with excessive hours.

Deadlines need to drop dead. Code quality suffers when you put a timeframe on it.

Features and stories should be completable in the span of an iteration.

Epics and Features are prioritized by the business and product. They can be expected to slide from iteration to iteration.

Any User Story or task should be expected to be completed an a single iteration.

If you keep having open stories stop bringing in a complete story. Just assign tasks.

Features and Epics are pointed.

Business looks at points earned per year or quarter. Look for trend.

IT leadership looks at amount of open stories and tasks that were moved from iteration back to the backlog. Over the span of all iterations.

This will ensure teams are breaking down work into actionable goals.

So said the 2 day scrum master

Good lord! Buzzword Bingo and Obfuscation at its finest!

Nothing personal, but you have just confirmed to me why i loathe the Agile/Scrum/[fad] processes so much. Take easily understood commonsense ideas/terms and invent fancy names for them, convert heuristics to axioms and sell a business around it.

> Even bad estimates are better than no estimates

Bad estimates are worse than no estimates, but if you are doing work complexity estimation and measuring velocity (which you need to do to evaluate internal process changes, manage workload, and for lots of other purposes), you are incidentally gathering the info you should need for excellent estimates, which are not necessarily hyperprecise but are excellent instead because they can explicitly quantify uncertainty as well as mean expected delivery time.

Reply on news.ycombinator.com