[commandlinefan]

> I won’t be mad about a long estimate

So... my experience with this mindset is that you won't be mad, but you'll just say "that's too long/expensive" and cancel the project entirely. Then the same project will come up again in two months with different wording, again and again, until I give you the estimate you think you can afford. And then the thing will end up taking longer than the original "too expensive" estimate (in part because too many things were rushed in the beginning to try to meet "the date"), but nobody will ever compare the final outcome against the original estimate anyway... because estimates are never meaningful.

[setr]

My rule of thumb is that if you give me an honest estimate, then it’s my job to make it work. Negotiate scope, change implementation, move resources, increase cost, whatever. But I need estimates that at least reasonably correspond to reality in order to make my case successfully.

The biggest issue I have is developers making business decisions without realizing it or without saying it — saying no to something because it would take too long or be too expensive, without first asking how much time/cost can be consumed

The same occurs with estimating — they’ll give a risky estimate instead of a safe one, because they’ll unilaterally decide the stable one is unacceptable; and not bother mentioning this with their estimate, or knowing what the rest of the timelines look like.

The other half of the problem is that people tend to only want to give one number (and people typically ask for a single number), but what you really want for project planning is the median +- margin of error timelines. The 1x,2x,3x rule is just a hack to work around that unwillingness.

[mason55]

Yeah, from the product management side this is the way to approach it. Make priorities clear and make it clear whether the important part is the date or some set of features.

If the date is what's important then start the conversation with "here's the date, can we get this all done by then? If not then what can we get done? If we can't do it all, here's the stuff that I think is important." And make sure to allow some time for people to think about things and give an honest estimate.

If the features are what's important then don't even put a real estimate on it because then that just turns into features + date which never works well. SWAG it by weeks or months and refine as you get further along.

It's basically a law that we always want t do more than we have time for, so it's important for the decision maker to be clear about which parts really matter.

[chii]

> the decision maker to be clear about which parts really matter

which is good and all, but the reason software projects have such a high failure rate is _because_ these decision makers aren't clear about which part really matter! And not to blame them solely, because it's a hard problem to know.

[jbverschoor]

100% agree. They aren’t clear because they don’t know. They might not be able to think in abstracts, or simply don’t have their priorities straight.

The same would happen with ANY other type of project.. marketing, home renovation, building an aircraft, or even baking a cake

[setr]

> And make sure to allow some time for people to think about things and give an honest estimate.

I like to tell people to give an estimate for when they can provide an estimate.. and estimate for that, if needed :)

Eventually someone knows something

[lazyasciiart]

The biggest issue I've seen is developers making business decisions knowingly, but without saying it to the business people. I was on a team that literally sat around saying "if we tell them it will take 18 months to do this then they'll just cancel it, but we want to do it, so let's say 6 months and then we'll just be late but they never cancel stuff in progress". I quit that team for many reasons, but they got started under that 6 month estimate and four years later the project is still going.

[b0bby]

My favorite PM to work with never wanted any estimates to be optimistic. Things had to be within reason, but he preferred very conservative to very lean. Once the numbers for a given proposal had been collected, it was his job (and anybody else from the team who went into the pricing/costing delegation) to go back and forth with segment management:

"We can't win with these numbers. Are you trying to lose this business for us?"

"Nope. I'm letting you know what we believe is necessary to finish the work on schedule. We can be more aggressive in some areas and, if so, we'll add items to our risk register."

"You need to hit XYZ target or we're not even going to send a bid."

"Roger."

<Team decides whether it is possible>

The internal cost debate usually ends up with a good budget and the PM/team have an "I told you so" card in their back pocket in case the team can't meet the delegated EBIT. It isn't perfect but this friction (PM sticking up for his team and management pushing for competitive numbers) is better than nothing. I imagine it is similar at most engineering shops.

edit: The fun part is that everybody knows its a game. PM wants as much cushion as possible, management wants great profit at a low price, and the team wants to keep getting work so as to stay employed. Sometimes the costing/pricing stuff goes a little over the top and the infamous "death spiral" gets tossed out by management. Always a hoot.

[majormajor]

I've seen this, but I don't think it was a problem or a bad thing.

Let's say the project was first proposed in January 2021. Got estimated as taking a year. Didn't get scheduled, since that was seen as too long, and there was other stuff people wanted done in 2021.

It's pitched again in June 2021. Same story.

Come Feburary 2022, it's pitched again. Now it's estimated as 15 months - there's more to do since more code has been written in the meantime! - and gets started, and ends up taking 19 months (estimates are never perfect!).

You might say "this was stupid, we should've just done it in January 2021" but in the cases I've seen, pushing it off a few times made perfect sense. The payoff wasn't seen as the most valuable thing that could be done, and the effort was high. The effort became higher after it was postponed, but by that point so was the relative value compared to other proposed projects.

On the other hand, if you hadn't come up with that first estimate, maybe the assumption is "ok this will take several months but we'll still be able to do this other stuff in 2021", but instead you work on it throughout 2021 and ship it in March 2022 or so (so ~15 months, still faster than doing it later), but that causes you to not do 80% of those other things you thought you could do.

Postponement or cancellation of a project because it's just too expensive to be worth it right now is a perfectly valid use of an estimate!

[marcosdumay]

Hum... The way to GP is written looks more like the scenario that the dev manager/PM/whatever comes to the team with the problem and gets the 1 year estimate, says "it's too expensive" and closes the project. A few weeks later, somebody states the problem again and pushes the manager to get another estimate, that is too large, so the project is closed.

Repeat that until the problem gets a singularly misleading wording, or some key person is away, and the project gets a 6 weeks estimation. It will take 19 months anyway, because nothing changed, but for 17 of those you will be late.

(Anyway, I have never seen a problem statement to be well defined enough for this to be the problem.)

[majormajor]

> Repeat that until the problem gets a singularly misleading wording, or some key person is away, and the project gets a 6 weeks estimation.

At that point we're definitely at a point of "severe company process problems" and the method outlined in the original article probably isn't feasible - I can't really imagine that manager accepting the time required to create a GOOD estimate - but I've definitely seen it work properly at some of my jobs.

[Pokepokalypse]

I've found that it's important to show your work - don't just cough up a number, show them your disciplined process at how you arrived at that number, (and I use PERT, as a process, and it's rarely steered me wrong).

As an engineer, it's my job to give an estimate. It's my boss' job to figure out whether that can work within his budget or if the task can be re-scoped. But I have to give him a number he knows is legitimate, and not some half assed BS I pulled out of my ass.

At a recent job, I witnessed an engineering team use some kind of agile "planning poker" game to arrive at estimates. Everyone on the team thought this was a great method. Yet they consistently failed to hit their targets, and it had a very profound impact on the performance of the ENTIRE company, (where various teams had serious backlog-coupling issues).

Because I'm a devops engineer (despite previously having been a development lead at a different company - which was a Fortune 500 by the way) and therefore, not considered a "real programmer" - of course I wasn't taken seriously when I tried to advocate a more data-driven, disciplined approach. But what do I know.

[mason55]

> my experience with this mindset is that you won't be mad, but you'll just say "that's too long/expensive" and cancel the project entirely

Well, as far as this stuff goes, I kind of have it on easymode because I'm a VP Eng who also does a bunch of product management work. When I'm doing product design, I have the benefit of knowing approximate engineering LoE/order of magnitude, so I can make sure that I design products where the engineering effort fits into the product development cycle.

But it's not unusual for something to be harder than I thought because of some detail that I'm just too far from to realize, and in those cases it's clear to the team that they should be honest with challenges and we'll work around them together, vs. some bullshit because they're afraid I won't like their estimate. The last part is built with trust though and basically never "shooting the messenger" when someone tells me that there's a challenge.

[stingraycharles]

I think this attitude is too fatalistic. A good approach would be to see if there’s some way to break up the feature in smaller pieces, into smaller milestones, etc.

If you have a manager that is unable to deal with this kind of stuff, then your problem is the manager, not the estimates. Estimates are extremely useful, and you’re doing yourself a disfavor if you think that they are never meaningful.

[commandlinefan]

If I was surrounded by people who could put together accurate software estimates that made upper management happy, and I was the only one who was always got it wrong, I'd hang up my hat and see if I could get a job selling life insurance. Hell, if 10% of my peers could put together accurate software estimates that made upper management happy, I'd lobby to have them elevated to senior positions and spend all my time begging them to explain their secrets.

But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.

The only thing an intelligent software developer can do is play along, learn to read subtle cues as to what they want you to say, say that, and get on with the actually messy business of delivering working software.

[mason55]

> because the people asking for the estimates don't actually know what the goals are

And this is the real problem. People who know how to build & design products should be able to explain the goals of what they're asking for. If they don't then either you need to move or you need to get them moved.

One of the first things I tell new engineering managers is that an easy hack to is to always be asking yourself "what am I trying to accomplish?" Whether it's an emotional conversation or writing a document, if you can't answer that question then you probably shouldn't be moving forward with whatever you're about to do. And if you're writing a document, make the very first section "The goal of this document is..." because as you write you can constantly ask yourself "is what I'm writing accomplishing my stated goal?"

Communicating your goal also helps your team - if they know the goal then they don't act as automatons following directions, they can make actual decisions on their own.

If you know the business goal of what you're building then you have a better shot at getting the requirements and tasks correct, which gives you a better shot at giving a good estimate. I've worked with a number of product managers who had no real goal behind what they were asking for. I refuse to have the team start building things until someone can explain why we're doing it and what we're trying to achieve.

[majormajor]

> But they don't. Nobody does. They don't just get the timelines wrong, they get the tasks and milestones wrong - which makes sense, because the people asking for the estimates don't actually know what the goals are, usually even after the software is delivered.

I definitely agree that the people asking don't actually know what the goals are. They usually have a very fuzzy picture there.

But I've always found the estimation and planning process to be hugely valuable for revealing the questions that reveal to THEM that they don't know all those requirements yet. And then we have a discussion about them, and we get better specs as a result, and then go on from there... which is way better than when we don't discover those gaps until we are writing the code for it!

[jbverschoor]

You’ll spend more than half the total time on meetings and discussing. Client will not be happy, but at least they can’t deny it was needed.

Still it’s the only way that works.

They pay for someone who types code, but need someone who understands their business.. oh wait, isn’t that a consultant?

Consultants get a bad name because they usually don’t understand either the business or the tech. But they have good verbal skills

[jbverschoor]

Just get more experienced developers, who understand that there needs to be done a lot more than writing some code. Pff wait, you’ll have to pay more, and you’ll have to trust their experience. Money and status…

It’s probably easier to get a younger dev who’ll go into crunch mode bc they made estimates based on incomplete specs and lack of experience, but who feel the responsibility to deliver. They’re more easily pressured into working more, when the PM should step in and get more resources or do damage control for the mess they created.