How to estimate work like a senior software engineer
Years ago, I interviewed at a company in downtown Boise. During one of the rounds, the panel asked me, “How many windows are there in Boise?” I had no idea. This was a technical position, after all. At a computer. (Maybe they meant Windows OS?)
I ended up getting the job and later heard from one of the panel members (then my coworker) that my response to that question was surprisingly informative and sparked a lot of conversation internally.
I’ve used a structured process for making estimates for the past decade. My estimates aren’t perfect, but I’ve found that estimates made with this approach are generally more accurate (closer to the actual outcome) than estimates made using other strategies (or, more often, no strategy at all).
Steps to make a great estimate
When someone asks for an estimate, they’re looking for more than a shot in the dark. You have information and experience that can inform a more accurate view of the problem.
Understand what’s being asked
Dig a bit deeper to uncover requirements lurking just below the surface request. 99 times out of 100, pushing for more details has led me to uncover more complexity (often after the asker assured me, “That’s all, seriously”).
In the estimate about windows in Boise, do we include windows in cars? Do glasses count as windows? Do we mean Windows OS? Can we nail down exactly what we’re trying to quantify?
Build a model of the system
This could be a diagram, a doodle, really anything. Whatever it is, get it written down somewhere. The act of transferring the model from your head to some other medium will help you think through the complexities involved with the system.
The number of windows in Boise is likely related to the number of people living in Boise, a figure we can easily grab. The population serves as a sufficient model for this single-dimension estimate.
For more complex systems (like the ones I build for my day job), I recommend diagramming. Often, a simple doodle will let you visualize and break apart your system.
Break the model into components
It’s easier (and more accurate) to estimate the individual pieces of the system than the system as a whole.
If I’m using the population figure as my model, I can use a single human as my base component. How many windows does one human have? I could guess one for their bedroom, two more for other windows in their home, five in their car, one at their office. That’s nine windows for one human.
Identify the components with the biggest risks
These risks might be “unknowns” but often hide behind “assumptions” about your understanding of the rest of the system. It’s important to label these assumptions.
“Nine windows to one human” makes a few critical assumptions. Let’s look at the car assumption. Five windows in a car assumes all people drive a car and don’t share it. It’s probably more likely that there’s one car for every two or three people, so we might reduce that number of car windows to two per person. And what about kids?
Make an estimate based on available information, and always gut-check it
It’s time to make the estimate. Part of making the estimate is saying it out loud (or writing it down). This moment is important because it gives you an opportunity to have a gut reaction to your estimate.
If you feel strongly like your estimate is off, go through the steps again. Don’t just make up a new number. You missed something, so take the time to do it right.
If you don’t like your estimate but the feeling isn’t very strong, you may need to power through the discomfort. Even if it’s the best estimate you can provide, estimating can feel risky. Try to remember that they asked for an estimate, not an answer.
I think it’s safe to make the estimate based on our guesses. 250,000 people in Boise, six windows per person, that’s 1.5M windows. That number doesn’t feel obscenely high, nor does it feel incredibly low. The gut check passes and I’ll stick with it.
Points that turn okay estimates into great estimates
Pick the right units
When someone asks for an estimate, you need to know if they need a high-accuracy estimate or if they’re looking for a ballpark number. Your response implies a degree of accuracy, so be intentional about how you quote your response.
If you give an estimate of “145 days” that implies a more accurate quote than saying “5 months”. Choose the units of your response that reflect the accuracy you’re estimating with.
Stubbornly defend your estimates
Estimates are more than just guesswork. Estimates are valuable data points based on your past experience. You’re not doing anyone favors by being wishy-washy with your estimates. Give a good estimate and stick to it.
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices — wait or eat it raw. Software customers have had the same choices.
— The Mythical Man-Month
An estimate is distinct from a deadline. They really aren’t related at all. But I’ve worked with more than a few teams that turn a given estimate into a deadline, or vice-versa. Disappointment is widespread.
Be courteously stubborn with your estimates.
Monitor progress against your estimate
As the project progresses, monitor the progress and compare your estimate with how the project is tracking. Close progress monitoring is a common (and proven) technique in other engineering disciplines.
We think it’s a great idea to record your estimates so you can see how close you were. If an overall estimate involved calculating subestimates, keep track of these as well. Often you’ll find your estimates are pretty good — in fact, after a while, you’ll come to expect this.
When an estimate turns out wrong, don’t just shrug and walk away — find out why. Maybe you chose some parameters that didn’t match the reality of the problem. Maybe your model was wrong. Whatever the reason, take some time to uncover what happened. If you do, your next estimate will be better.
— The Pragmatic Programmer
When the schedule starts to slip, the natural response is to add more resources to get the project back on schedule. This will make it worse. Instead, learn from your mistake going forward and let the feedback loop inform future estimates.
Above all, review and adjust your estimates as you go along. Iterate your estimates along with the project. Remember that your estimates are estimates, not deadlines. Estimates are subject to change as you learn more. As you get closer to the end of a project, the estimate should get more accurate.
”I’ll get back to you.”
Wherever possible, avoid giving an answer immediately when asked for an estimate. That will be more of a guess. Slow the process down, go through the steps, and come back with a higher-confidence estimate later.
Part of getting a good estimate can include asking others for their input. Most of my estimating at Medium involves 1:1s with other engineers that have either built similar systems in similar contexts or have other relevant experience. I’ll ask them for their thoughts on the system I’m being asked about. Their insight informs but does not decide my estimate.
Making good estimates is an underrated skill. Like any other skill, you get better by doing more of it.