How I estimate work as a staff software engineer
44 points by lalitm
44 points by lalitm
TLDR: he doesn’t estimate work, he figures out how much time his management chain will give a project and figures out some plans that look like what they’re talking about.
A little nuance: he gets the political context in order to present them with a few options that can work within the available time, and informs them about the pros and cons.
Maybe (if we read between the lines) the real profit in the author's strategy is that, by understanding the political context, they identify who the project sponsor is. I think that in large organizations it can be unclear who's really pushing/advocating for a project; one may think that their project manager is also the project sponsor, or that their boss is the person that wants the project to succeed. But by finding out who is at the top of this project, the engineer may maneuver the planning phases more successfully.
I think what this article (and much of the other discourse around project estimation) misses is that estimation isn't a one-and-done thing. It is absolutely reasonable for engineering leadership to ask "how long will this take?"
The response should always be of the form, "based on what i know right now, I think it will take this long, but here are the places where that estimation is uncertain". And then, if and when things go off the rails, communicate that upwards: "this part is taking longer than i expected because of X, Y, and Z, here's what we're doing to address that, and here's how my timeline has changed because of this new information." Estimates can (and should) get revised all the time, as you learn new information.
I've (almost) never had a manager or leader get upset if I proactively communicate upwards about status or estimates. Where folks get really upset is when you try to hide the fact that you're behind, or make it appear that the situation is out of control.
And really, that element of control is the most important bit. At the end of the day, the estimate doesn't matter, what leadership wants is to feel like they're in control. So give them the information they need to feel that way.
I just make a good guess at how long I feel like it should take, and then multiply by four.
Works really well, weirdly.
In grad school, a fellow student told me about his "tau rule": whenever a professor tells you how long something will take, multiply it by tau, i.e., 2π, and you'll get the true amount of time. Shortly after, my professor told me something would take a week to happen, so I tracked it and found it took a month and half until it was done.
I feel this is correct and lines up with my past experience. The add 20% rule seems way too slim. Usually I underestimate by multiples. I will borrow this.
This is exactly my strategy but I only multiply by 2. Perhaps I'm more naturally pessimistic.
When I estimate work to be done myself I tend to land it pretty solid, 20-30% spread maybe. In teams I can also estimate work for people whose capabilities I know (just by using a multiplier/divider over estimating it for myself). There is no science or heuristic: you just look at the problem and the estimate kind of bubbles up. I know it sound like going off a vibe but it works. Enough so that I feel confident sending a PO to consulting companies for specific amount of man-days based on that.
Have to admit tho it got a lot better with experience and probably would not translate between vastly different domains very well.
Software estimates are fundamentally about power: management wants as much as possible, as quickly as possible, engineers want to do as little as possible, as slowly as possible. In my view, it makes no sense at all for management to ask engineers for estimates in this context -- instead, work should be delivered continuously and without fixed deadlines, Kanban style, aligning management and engineers in the same direction.
engineers want to do as little as possible, as slowly as possible
This is a huge generalisation that certainly does not reflect my experience of the colleagues I would prefer most to work with. We are generally excited by the work, and want to do as much as possible! This is in fact one of the things that makes estimation challenging, when enthusiasm causes us to overestimate how much we're going to be able to achieve in a limited amount of time.
work should be delivered continuously and without fixed deadlines
I agree that this is a reasonable preference, but the practical reality is that there are often hard deadlines! Many engineering efforts need to co-ordinate software delivery with other parts of the business that have more complex scheduling, such as a hardware release or services delivery or marketing event.
There are also often needs to draw a boundary around a particular scope of work. Something is not really a project if it doesn't have some criteria by which you can tell when it's finished, and then drive towards actually finishing it. Sometimes there is a limited pool of money to spend on a given project.
engineers want to do as little as possible, as slowly as possibleThis is a huge generalisation that certainly does not reflect my experience of the colleagues I would prefer most to work with. We are generally excited by the work, and want to do as much as possible!
I think a more useful way to describe the dynamic is that managers want the code to be as low-quality as possible and engineers want the code to be as high-quality as possible. To a rough approximation this looks like as fast as possible vs as slow as possible if you are just looking at "number of features shipped" which most managers do, because they haven't read Seeing Like a State.
Whenever software estimates come up I always mention the range method: provide two times: the time it would take if everything goes smooth and the time it takes if all the unknowns appear to be really tricky.
This gives management a lot of information: the minimum time, the maximum time and the uncertainty.
Back at university, I came up with a joke: a coefficient T such that, if you multiply any wrong answer by T, you get the right one. Many--far too many--years later, I realized that in software engineering estimates, this coefficient tends to converge to π.
That's my strategy! I think of an amount of time and before I say it out loud I multiply it by three!
I only estimate work that I've done in the past in the similar working setup/condition. Anything I've never done before - does not make sense because I don't know what I don't know. Btw, this is scrum/agile in 2 sentences.
Otherwise I always say "It will be ready when it's ready" if you want something that users are happy about or I can give you a half working MVP in X days and you take customer success in your hands
good overall approach, though doesn't "filter to software approaches that will meet a political estimate" also require estimating how long each approach will take?? or is it again just "each estimate made for political reasons carries a certain priority" and that priority is what informs how you approach things.
The question of estimates is something that attracts me a lot because I've worked in teams and companies that do (or don't do) estimates in really different ways. A couple of years ago, I wanted answers that (I hoped) would feel authoritative. I read Bob Martin's "Clean Agile"; I found it to be well-written and balanced. I thought it was less opinionated than "Clean Code" or, perhaps, that he managed to present enough arguments and counterarguments so that the reader gets a better picture of the problems with planning software projects.
He writes that, for software projects, one can choose three out of four: good, cheap, fast, and done. I don't know yet if I fully buy into this premise. I think, however, that it is interesting to think about. When I've mentioned this to management and other leadership, I find some resistance to this idea and its implications: that if we want to meet a deadline, we might need to adjust the project's scope or the timeline itself. It's like I've touched a nerve every time I bring it up. And I wonder if it's the same across the industry, or if some organizations have already figured out what works for them and where estimates are not a "hot" or contentious topic.
In this thread we have people saying the following estimate multipliers all seem to work for them: 1 (maybe 1.2), 2, π , 4, 2π. Just making that observation :)