Estimates Are Not The Same As Deadlines

Some in management treat estimates as deadlines leading down a slippery slope that results inefficiencies and burnout.

An estimate is like a preliminary map, a sense of direction and scope—much like what Howard Carter had when he set out to find King Tut’s tomb. It’s a starting point, a rough outline of where to dig. But estimates are not deadlines. They’re not declarations of certainty but of possibility, which, as Carter’s journey shows, is crucial when embarking on complex, unpredictable ventures.

Howard Carter didn’t find Tutankhamun’s tomb on his first dig, or even his tenth. He worked tirelessly, year after year, funded by Lord Carnarvon’s resources and trust. Carter’s team toiled under the hot Egyptian sun, turning over rock after rock, endlessly surveying and adjusting their methods as they learned more about the geography and ancient burial practices. In software, our projects also require that blend of perseverance and adaptation. Like Carter’s early dig sites, our estimates set the stage, giving us a sense of what lies ahead. But we can’t let these early assumptions confine us.

Carter, like a developer diving into an unknown codebase, had initial “estimates” about where the tomb might be, based on fragments of information from previous excavations and ancient records. But as he dug, new details emerged, requiring him to shift plans. His estimate of “how long” or “how deep” was, by necessity, flexible. In software, too, we begin with a vision, but each layer we uncover—technical debt, unforeseen bugs, and design complexities—often demands that we revise our initial estimates. By treating these preliminary calculations as flexible guides rather than strict deadlines, we’re free to pursue quality solutions instead of rushing to finish just anywhere.

For Carter, the process was often tedious, like refining code that never seems to quite work as expected. There were countless dead ends, where no trace of a tomb was found. Imagine if he had been held to a rigid timeline, pressured to produce a fully excavated tomb by a specific date. This pressure would have forced him to cut corners, perhaps missing the hidden stairway to Tutankhamun’s tomb that he eventually unearthed after years of patient work. Similarly, in software, when we treat estimates as deadlines, we risk hurrying through critical steps, skipping essential testing, or bypassing structural improvements. The result is often code that’s less robust, less adaptable, and ultimately less valuable than if we’d allowed for flexibility.

A deadline is a point in time when results are required—an absolute. It’s Lord Carnarvon knocking on Carter’s door, expecting news after years of investment. An estimate, however, is the map Carter had of the Valley of the Kings—a rough idea of where to start digging, but one that allowed for course corrections and new discoveries. Carter couldn’t predict the exact day he would uncover Tutankhamun’s tomb; he could only estimate how long it might take based on limited information and revise his expectations as he learned. This is the mindset we need in software development: a willingness to start with a hypothesis but adapt as we dig deeper and gain more information.

Estimates are provisional, like Carter’s initial survey of the valley; they’re guides rather than guarantees. By respecting this distinction, we set our projects up for success, allowing room for the inevitable surprises that arise in software development. We’re free to investigate, experiment, and find solutions that work for the long term. This difference between estimates and deadlines means that while we start with assumptions, we’re not shackled by them, just as Carter wasn’t locked into one digging strategy.

When we estimate, we do so with the same mix of excitement and caution that Carter had at the beginning of his work. Estimates should be treated as sketches of what might lie ahead, not final destinations. In the end, Carter’s relentless adaptability led him to an extraordinary discovery that was worth every deviation from his initial plan. Likewise, by treating our estimates as flexible, we too can reach goals that exceed our initial expectations, ultimately creating software that feels as remarkable as the treasures of Tutankhamun’s tomb.

So the next time we’re pressed to meet a software “deadline” based on an early estimate, let’s remember Howard Carter—his patience, his persistence, and his respect for the unknown. Just as Carter dug carefully, open to redrawing his maps with each new clue, we can let our estimates guide us while we adapt to the discoveries along the way. In software, as in archaeology, true progress depends on the freedom to follow the evidence, no matter how long it takes.