[ColinHayhurst]

> Estimates are one of the hardest parts of software development.

And also fundamental. When I was directly estimating big software projects the key, for me, was to trust developers recommendations but apply a different multiplier for each developer. Multipliers ranged from x1 to x3. Those rare devs with x1 were, of course, a blessing. And those with x3 were not necessarily bad; they were often the ones working on the really hard problems. Of course, it meant getting to know those developers and a prior (which we set at x2, for new starters).

Individuals were remarkably consistent in terms of their actual performance; so a x1 developer would almost always be a x1; a x1.5 would almost always be x1.5.

[mason55]

One thing I’ve found to be helpful is to make it clear that I won’t be mad about a long estimate

If that’s how long it’s going to take then that’s how long it’s going to take. I think there’s a group of people who are used to getting lots of pushback on their estimates and so they estimate low to avoid that conflict. The future conflict of things being late is not something they have to deal with right now and maybe they actually will get it done.

The key is backing it up continually and really not getting mad about estimates that are longer than I’d like. And, for people who I do think are sandbagging, asking more specific questions about the details of the estimate in a non-combative way.

And of course some people really are bad at estimating. But I find if they don’t improve with coaching then it’s a symptom of a bigger problem (not thinking things through all the way) which manifests in other ways beyond estimation (eg poor design)

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

[crooked-v]

I'm reminded of the classic saying: "The first 95% of the work takes 95% of the time, and the last 5% of the work takes the other 95% of the time."

[mtippett]

Arggh.

I hate multipliers. It's not poor estimates that need to be doubled. It's the lack of experience in identifying the complexity or likely risks in a project.

So rather than multiply, ask for risks. You'll find that most engineers know the risks (or at least they may know it is without risk). As you explore risks, you'll find the estimates will lengthen automatically.

So rather than do the multiplier, explore the risks. They are what makes projects late, not intrinsic engineer productivity. You'll end up with better engineers who know themselves and their problem spaces better. You'll also get a clearer view of what could screw up your project.

[feoren]

I don't think OP is saying one engineer is 3x "more productive"; rather they're saying that engineers tend to be consistent in how much they over- or under-estimate tasks. It sounds a little like "story points", where each developer may end up having their own estimation scale.

[nudgeee]

I agree that project risks should be explored and multipliers are not substitutes for them. However multipliers are useful for ongoing dynamic distractions outside of the project that reduce your productivity, for example company meetings, hiring/debriefs, getting pulled into critical bugs, helping to support colleagues, etc.

[YZF]

I don't trust multipliers. I often find those rules of thumb to be very poor predictors. Since if you don't know how can you predict some fixed fraction of the work?

I led a small team to deliver software over a multi-year project. The software was used to control a machine. The machine was contracted as part of a multi-million dollar deal. We delivered software on time and with good quality. It was very far from trivial. The key to this is that the team had experience in doing similar projects, so we generally knew how long things take. We knew what needed to get done. We knew we would be debugging the machines. We knew we would need to work around issues. We knew we'd be limited until the first prototypes are assembled. We knew what existing tools and libraries we could reuse. And we also knew what's the minimal viable product and what are nice to haves. For me personally this was the third consecutive project of building very similar machine control software, for very similar applications, using very similar technologies. This wasn't exactly the same but I went through this process and I knew how it works. The first of those actually failed because the software wasn't ready on time (and other reasons, but that was the main one).

A team with no experience, building something new, has zero chance of correctly estimating anything. Not only will they likely not deliver on time, they might not deliver at all, ever. Or they'll deliver something that doesn't work. Someone external who has experience with these teams might be able to provide the right estimate (e.g. they'll say it'll take them 3 years and they'll deliver nothing). In my current job I asked a junior engineer for an estimate, he broke down stuff to tasks, and came back with something like "a month". Ten months later it wasn't done. Much simpler technically than the other project but the engineer didn't really see all the details, didn't have experience with similar projects, so he basically just made stuff up.

You always have to plan for surprises and you need to have contingencies. An estimate is always some sort of distribution but for a large enough project these distributions do form some sort of coherent picture. Sure, you might have a surprise, but you do the risky things first to reduce those risks.

[mtippett]

Yay #noestimatemultipliers

[ChrisMarshallNY]

Good management advice. I was a first-line manager for a Japanese company (hard estimates, with lots of international frowny-faces, if the estimate was missed). That was pretty much what I did.

We usually came relatively close to our estimates, but would sometimes encounter anomalous situations that would force us to re-evaluate. I found that my managers were pretty good at accepting these, as long as they were not too frequent, and as long as I didn't do the "Lucy in the Chocolate Factory" thing. They set hard plans, and we were not to deviate from them.

But our customers often did not like the software that we delivered on-time, and to-spec. Since we were a hardware company, it was considered OK, but we hated it.

So we delivered yesterday's technology; tomorrow. :(

But I also ran a small team of really high-functioning C++ engineers. They stayed with me for decades, and I got to know them quite well.

I can't even imagine running one of these shops with half a million inexperienced engineers that flow in and out like guppies in a pond. My management experience would be worthless for that environment.

Since leaving, I have taken a very different tack with the software that I write.

I assume that my estimates are basically fiction. I am going to make big changes, to suit changes in the deployment environment, customer expectations, competitive landscape, platform tech, etc.

I tend to write very flexible software, in layers and modules. It allows me to react to these changes fairly quickly, and to maintain my very high quality standards, throughout.

I often toss out huge gobs of code, when I hit one of these challenges. That actually makes me happy. The code I don't write, is the best code of all.

Flexible software is a very double-edged sword. Most quality processes advise against it; for good reason.

But I tend to know what I'm doing. I've been at this a long time, and have been very humbled by many, many mistakes. I would probably have a difficult time trusting developers with lesser experience to take the kinds of chances that I take.

So my personal process depends heavily on me being me. I know myself, fairly well; warts and all. This means that I can trust the Principal engineer on my projects.

I manage scope. My projects are small-batch, artisanal, projects. I don't bite off more than I can chew. That said, my "small batches" are bigger than a lot of folks' personal projects. I often spend months, writing my code, so change comes almost invariably, during my projects.

Works for me. YMMV.

[xcambar]

Honest question: how do you function in a team?

I know a bunch of very self-aware devs, but they almost all have a very double-edged relationship with team work: theylove to learn and share yet see other people as impediments or risks on their way to delivery.

How to improve on these situations?

[ChrisMarshallNY]

Very well. You don’t last long in a Japanese company, if you don’t “team” well.

I lasted for almost 27 years.

I’m working on a team, now. I am doing the native app development, and I was the original author of a couple of the servers, but there’s a relatively young chap, working on another server (we’re up to 3 servers). He has some experience, but nowhere near mine. I’ve learned to work with a light touch, in these circumstances. I demand a lot, from myself, and expect his work to meet my bar -but only at the API level. I stay out of his kitchen. I make sure that he has no problem, asking me any questions, or for help.

When he asks for help, I immediately provide it, with no judgment. In turn, he has introduced me to a couple of new tools and techniques that I have adopted.

Here's an example:

Before this project, I'd never used Postman. I used much simpler REST explorers. You'd probably laugh at the primitive tools I used, when developing my servers.

I suspect that you wouldn't laugh at the results, though.

He asked if I could use Postman to give him examples of using the API for one of the servers that I wrote.

I could have been a dick, and said "RTFM" (It's a very well-documented API). Instead, I learned Postman. Didn't take long. He's thrilled at the results. Our exchanges seldom take more than a couple of Slack messages and a Postman query example.

I now have experience using Postman, and will have a new tool at my disposal, for working with others. It probably won't be a regular part of my solo work (Insisting on using team tools for solo work can be a bit problematic), but it's nice for teams.

I am encouraging him to learn Charles Proxy. He's not really following up on that. It's not the end of the world, but he's missing out on some really awesome inspection capabilities by ignoring the tool (and it means that I have to be a bit more creative with my Postman examples). It may cause problems down the road, and I'll deal with them, if they crop up. I will do so in a non-judgmental way. Our relationship is valuable, and needs to be treated with respect. I treat him with respect, and he does the same for me.

In my world, that’s how we team.

[andruby]

Do you mind explaining why you say estimating is fundamental?

I don’t disagree that it is important, I probably wouldn’t label it as fundamental, at least in a context of a company developing its own software internally.

[majormajor]

Even when developing your own stuff internally, you have a limited resource: your dev team's capacity to do work.

The most important question for your internal software team is still "what should we work on" and estimates are a fundamental part of answering that.

It's someone's job to figure out what things that team could do to provide the highest value. Usually some combo of product/sales/marketing/tech.

But that's only half the equation! You also want to know how much it's going to cost, in terms of those scarce dev resources. If one project would add X value but take a year, and another set of projects would add Y, Z, and A value, but each only take four months, you want to compare Y+Z+A vs X to see what gets you the most value over the next year. So the better the estimates, the more rational you can be about what work gets done. If you have no estimates, you might pick a project that will go on for way too long, and not get the value out of it that you expected.

(However, I doubt anywhere truly uses NO estimates. I've never seen a place that didn't at least have an informal level like "oh that'll be really hard" or "that'll take us a long time.")

[tikhonj]

There's a qualitative difference between the sort of informal estimates you mentioned ("it'll be hard") vs the sort talked about here—people don't treat the informal estimates as commitments!

As soon as an estimate is really a commitment it totally changes the dynamics around it and actively impacts autonomy, so my impression is that what people mean by "no estimates" is more like "no timeline commitments".

[x0x0]

It's one of the top two or three most important things.

All teams have far more work than they can possibly do. A handful of things win; most things lose. Reasonable cost tradeoffs to pick which two or three things per quarter get worked on require estimates. And even in small startups, millions of dollars are spent on salaries per those decisions.

[ColinHayhurst]

Fair enough. It was the word that came to mind and I might have used a better one. Important doesn't quite capture it. Time is invariably the most precious resource, so perhaps "crucial".

[satyrnein]

Joel Spolsky's team actually built that approach into a feature: https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

[HillRat]

Fogbugz really was (is!) an underappreciated product. Jira’s become a necessary evil, but I really wish FB had managed to make a bigger dent in the market.

[phist_mcgee]

Something about the letter 'z' always screams out to me as a forgotten marker of 90s-00s culture. Really, any substitution for the letter 's' these days feels almost _antiquated_.

[eikenberry]

Did you ever come across a person who was < x1, like a x0.5 (they overestimated)? I know developers generally undershoot, which is why we joke about making your best estimate and multiplying it by 2-3. But does no one really ever reliably overestimates?

If the answer is never or rarely then that lends a reasonable amount of credence to the idea of just multiplying your estimates. Because you most likely should and the chance of overestimating is low.

[ColinHayhurst]

Not in my experience

[twelvechairs]

Estimation depends on the unknowns which you can typically put down to overall task time and complexity of the task. If its is something they have done before and a short task (hours), x1 is fine. If it is something new and long (weeks), x5 may be underselling it.

Breaking down a long task to be as granular as possible then rating each component against a scale of how much experience/confidence you have is the best approach to managing risk. As a manager, if you aren't asking people to explain this, you should be.

I've never seen anyone do it (I also haven't worked anywhere massive), but monte-carlo analysis with a tornado chart etc. would be the best way of managing this kind of risk at a complex-systems scale. It is a system used by the top real-estate developers.

[bsder]

I find that if you take the estimates and roll them up statistically, you get a pretty good result.

The problem is that everybody schedules to the estimate assuming it's the 90% point (project done) when it's actually a pretty accurate mean (50% point). In reality, the number is probably closer to the 33% probability because software can be an unbounded amount of time late but only a bounded amount of time early.

The primary problem is that when you feed people the 90% number up front they freak out. The secondary problem is that nobody goes back after the project was done and checks whether the 90% estimate was accurate (it generally is pretty close).

[LegitShady]

The multiplier was the same way I dealt with estimating time budget for homework in university. I would estimate the amount of time I thought it should take and multiply by 3 and it would usually take between 2-3x at the end.

It's a little harder when the work is more nebulous and I don't have to do it for others but it's all based on personal estimations of productivity as well as understanding of the problem. It's not easy to do.

[killjoywashere]

A Jira plug-in to use some sort of Bayesian system to adjust developer priors at the task and sprint level. That would be amazing.

[msluyter]

Yeah I've always felt like the missing part of the loop (in the context of pointing stories) is looking at point estimates and then tracking how accurate they were, _by developer_. E.g., I throw 2 points, but it turns out the story takes something along the lines of 13 points, then my estimation was pretty low and my personal "estimation multiplier" is increased. Subsequently, actual point estimations could take the estimation multiplier into effect.

Of course, this is mostly a toy idea that's fun to think about, but seems pretty untenable given that it requires keeping track of time, which most developers hate. That, and there'd no doubt be incentive to game the system by padding estimates or other shenanigans.

[killjoywashere]

Just look at completion rates within sprint. How many points did they commit to, how many did they finish. 2 weeks is a fine unit of time.

[tel]

FogBugz used to do something of that nature. I never used it, so I'm not sure how well it worked out ultimately.

[ska]

Individual factors are useful, but I've also found it very effective to ask for more that one confidence level, e.g. tell me how long you think it will take with 95% confidence, and with 50%. The spread on these is informative.

[ragebol]

How much learning time did you typically need to arrive at that multiplier?

[ColinHayhurst]

At the end of two completed projects from each new starter