“I just have two emails to send, and then I’ll stop working for the day. Give me 30 minutes.”
This is what I said to my wife of 16 years last night. I made a 30-minute estimate in a split-second and promptly dove into the work. And those two emails? They actually took 90 minutes. One of them took nearly 45 minutes to craft. The other one exploded into three separate emails, a few adjustments in our company time-tracking software, and a short chat with Casey before I actually clicked the send button. My 30-minute estimate changed into a 90 minute project. And then I worked for another hour beyond that.
How could I have been so wrong? Those emails took me three times longer than I predicted. Worse yet, these were two very small tasks. I wasn’t estimating something that could take weeks or months. I was estimating my next 30 minutes. I was undistracted, my laptop was already open, and I even had the first email started.
A major portion of my job is to write emails and to communicate with people. So I should know how long it takes to write emails like these. Right? Wrong.
Estimates are lies.
Two things everyone fails to remember about estimates:
Every estimate predicts the future. As professionals, we’re charged with playing fortune teller. Since we have a depth of knowledge about software development, you count on us to know the effort it will take to make something. And we do know, sort of. Except no one has tried to build your exact app with your exact needs. Trying to quantify the complexities of what may happen in the next week, next day, next hour (much less quantify it in a simple “it’ll take this long” number) … well, it’s an odd practice. How can we ever really know?
The understanding of the task changes greatly once the task starts and as it evolves. I estimated thirty minutes for those emails because an email usually takes me around 15 minutes to complete. At the point of estimating, it didn’t occur to me that one of those emails would require input from another person. And I didn’t realize that in order to communicate effectively with my team I’d need to send two more related to the second email. These tasks became obvious as I did the work.
Could I have done better?
Maybe. I might have recognized that typically when I wait until the end of the day to send an email, it is because those messages take more thinking and thus take more time. Maybe I could spend some time classifying the types of emails I send, and computing the average compose-and-send times for each type. But that feels like overkill.
For sure I could have taken a breather after the first 45-minute long message, and told my wife that it is taking longer than expected. But methodically thinking through every step of writing these two emails before doing so just so I could have a more accurate estimate would have been madness. How much time would I have spent trying to uncover and estimate those sub-tasks? That amount of work up front doesn’t add value. Pausing to craft an accurate estimate of the time it would take to send those emails wouldn’t have changed the fact that I still needed to get them sent. It would have taken more time … time that could have been better spent elsewhere. So I estimated based on the tasks in front of me: write two emails.
But I estimated wrong.
Estimates are our best guess — at the time
Perhaps “All Estimates Are Lies” is too harsh. After all, we’re not trying to mislead anyone. And we certainly don’t fault our clients for asking: we know estimates are essential to planning for what’s often a significant expense. But we also know that any estimate we share is a single point-in-time view of what the future might look like. The further we get into a project and the older our estimate becomes, the less accurate it becomes.
I think The Retrospective Prime Directive speaks well to this. “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Rewritten for estimating, one might say: “Regardless of what has happened throughout the project, we understand and truly believe that the estimates given at the beginning were the best guess we could produce given what we knew at the time, our skills and abilities, the resources available, and the situation at hand.”
Building new software is a creative act
Custom software is not a manufacturing assembly line. What we make for one client can not be re-used for other clients. Sure there can be similarities between projects, but those similarities are never as deep as you would think. Truthfully, I’m amazed by how little re-use there is from project to project. Each client comes with different ideas and different requirements. And that is okay. Because the Software for Good value is not in our ability to re-use pre-created widgets. Our value is in understanding your unique business needs, rapidly comprehending the specific technical tools needed to meet your goals, and then working hard and efficiently to achieve those goals.
A commitment to communicate
Given all this uncertainty in developing estimates and building software, why choose Software for Good? Because we’re transparent about it. Our promise to you is that we will communicate regularly and openly throughout the entire process. When the project takes an unexpected hard left turn, you’ll see how that impacts cost, effort, and timeline before we begin the work. You’re in the driver’s seat, steering the project in the direction you want it to go. We will provide feedback throughout the process, of course, but if you’re ever unhappy with how the project is unfolding, you’re free to pull the plug, take your partially-complete software and bring it to another development shop (more on that in an upcoming post).